[guardian-dev] OTRDATA draft specifications

[Hans-Christoph Steiner]

On 10/13/2013 05:35 PM, Kevin Steen wrote:
> On 13/10/13 20:44, Dev Random wrote:
>> Here is a preliminary draft of the Guardian OTRDATA specifications.  The
>> purpose of this specification is to standardize data transfer and
>> request/response oriented applications inside the encrypted OTR channel.
>>
>> https://dev.guardianproject.info/projects/gibberbot/wiki/OTRDATA_Specifications
> 
> I may be misunderstanding the OTR specfication, but it seems like it
> requires acknowledgement of every packet, with no more than 2 packets
> allowed to be unacknowledged at any point?
> 
> On a high-latency network connection (e.g. Both ends using WiFi) I think
> this will seriously limit the transfer rate achievable and effectively
> make file transfers impractical - especially when combined with the
> base-64 encoding drastically reducing the available bandwidth. The TCP
> protocol can only utilise the full bandwidth of a link when it can
> expand its window and have many packets in-flight.
> 
> That said, I believe the specification is still extremely useful for
> allowing smaller data exchanges between compatible plugins on each end.
> 
> Three things I think should be added to the specification:
> 1. Explicitly list the allowed Response codes, even if just to reference
> the HTTP specification.
> 2. Provide a way to request a list of available remote applications,
> rather than having to enumerate each one and check for a 404 response.
> e.g. GET chatsecure:/meta/applications
> 3. Document a standard location for reserving application identifiers to
> guarantee uniqueness & interoperability (e.g. A wiki page somewhere) -
> the android method of using domain names fails as time passes and people
> move domains. Perhaps recommend that plugin writers generate and
> document a GUID?
> 
> The use case I'm thinking of is to use the OTR session between multiple
> devices to sync data from multiple applications (e.g. Contacts,
> bookmarks, etc.)
> 
> -Kevin

I agree with Kevin's points.  I'll add some more comments.  I'm having a hard
time visualizing the whole interaction over OTRDATA without any mention of
authentication.  This particular API does not have any auth built into it.  It
seems that for OTRDATA to be widely useful, it will need to have relatively
fine-grained permissions.  For example, if I want to share my location with a
list of my buddies, then there will need to be a mechanism somewhere to
enforce that.  It will then be tricky to make that manageable without having
some crazy Access Control List UI.

What about using a push model for OTRDATA?  This would work well for file
transfer and sharing bits of data like location.  Then permissions become more
like a list of recipients.  I don't really have this idea fleshed out, but its
just a hunch that it might be easier from this point of view.

And two little points about the wiki page:

* client-client is peer-to-peer, no?
* why max packet size of 64k?

.hc


-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81