#13 Documentation of the protocol

Closed
opened 7 months ago by EmanuelLoos · 2 comments

A documentation of the protocol might be a good idea. That way it could be implemented in other software like Chatty. Documentation can also be helpful if the project ever is not developed by you anymore.

A documentation of the protocol might be a good idea. That way it could be implemented in other software like [Chatty](https://source.puri.sm/Librem5/chatty). Documentation can also be helpful if the project ever is not developed by you anymore.
dx commented 7 months ago
Owner

Good idea, I wanted to document the protocol too but there may be some changes coming especially for the call over tor feature so I might wait until that is done, also frankly there are tasks that are higher priority right now and the protocol itself is very straight forward and it's only written in 2 files: TorClient and TorServer.

Nevertheless this must be done and hopefully I will get around to doing it soon.

Good idea, I wanted to document the protocol too but there may be some changes coming especially for the call over tor feature so I might wait until that is done, also frankly there are tasks that are higher priority right now and the protocol itself is very straight forward and it's only written in 2 files: TorClient and TorServer. Nevertheless this must be done and hopefully I will get around to doing it soon.
Emanuel Loos commented 6 months ago
Poster

A few things that should be considered as well: A protocol should be future proof, backwards compatible. For example it would be good if the peers exchanged the highest version of the protocol they support. Regarding calls it would be good if the protocol would be open to adding newer codecs later without breaking backwards compatibility. On the other hand anonymity can only be preserved if many users look the same. This always needs to be considered especially since this is a requirement that is more specific to your software, something that normally does not count. On the other hand there are nicknames making it kind of pseudonymous. Calls are constantly consuming bandwidth, someone using another codec might stand out.

What I mainly want to say is a protocol should be thought through since you might be stuck with it for a long time and when all use different options this might also be problematic for anonymity. It should not be defined in a rush.

A few things that should be considered as well: A protocol should be future proof, backwards compatible. For example it would be good if the peers exchanged the highest version of the protocol they support. Regarding calls it would be good if the protocol would be open to adding newer codecs later without breaking backwards compatibility. On the other hand anonymity can only be preserved if many users look the same. This always needs to be considered especially since this is a requirement that is more specific to your software, something that normally does not count. On the other hand there are nicknames making it kind of pseudonymous. Calls are constantly consuming bandwidth, someone using another codec might stand out. What I mainly want to say is a protocol should be thought through since you might be stuck with it for a long time and when all use different options this might also be problematic for anonymity. It should not be defined in a rush.
Sign in to join this conversation.
No Label
No Milestone
No assignee
2 Participants
Loading...
Cancel
Save
There is no content yet.