This is meant to keep track of what protocols we think or want to support in tree. Remember, we are only supporting open source/spec protocols in tree now.
We also need to decide which protocol we want to implement next. Right now I’m leaning towards sip/simple, simple specifically since the chat features are very basic and we would have a good base to start on voice calls with sip when we’re ready for that.
irc (already implemented more or less)
xmpp (based on our libxeme)
bonjour (based on our libxeme)
matrix (based on our libmyna)
sip/simple (based on libsofia)
rocket.chat
mattermost
activity pub (mastodon, goto social, et al)
@at (blusky)
On top of that, we need to decide which to implement next. So…
SIP is more complex than XMPP for IM and calls, but is widely deployed. Sort of. Me talking to typical business owner with “SIP” phones: “So can you make SIP calls with your SIP phones?” BO: “SIP calls? What are those?” Me: “You know, call name@domain - it’s like email except for phone/video calls and IMs.” BO: “…”
I use XMPP calls from Pidgin a lot. It works great, but the echo cancellation in the audio library is not as good as whatever you get with Element web for matrix in firefox. I have an old fashioned telephone handset that plugs into the headphone/mic jack for that problem.
One more thing: SIP support should handle raw IPs. This allows p2p SIP calls without a SIP “server”. Of course you also don’t get server features like call transfer, etc - but it is dirt simple to use without being vulnerable to centralized DNS and TLS, and the address book takes care of memorizing those pesky IP addresses. Use a cryptomesh IPv6 network (cjdns,yggdrasil,pinecone,etc) to avoid any dependency on IANA as well and provide e2e encryption and authentication.
Looking at “Manage Accounts”, it is not clear how you would create a p2p “account”. There is no login and no server. Maybe leave password blank? You do need a user, as that is part of SIP protocol. XMPP server is so light, it is no big deal to just run one on local machine. SIP server is larger and more complex - so P2P support for a client is that much more important.
Another P2P issue for Pidgin users is likely to be firewall setup. SIP is one of those protocols like FTP that uses a bunch of ports. Configuring firewalld or other to work with P2P SIP is not trivial.
I assume you’re looking at Pidgin 2. For Pidgin 3 we have a lot of stuff to do / change to make stuff like that possible. The biggest of which is overhauling authentication which is why everything is forced to have a username.
We have to work about NAT’s and firewalls for all sorts of stuff. We’ve started traversity to deal with all of that but it’s far from usable as we’ve been focusing on other things at the moment and haven’t gotten to a point where we really need it yet. Obviously this won’t get through an aggressive corporate firewall but it should help a good number of users.
Yes, there is no registration. You do need a username, because that is part of SIP protocol. But there is no password. A nice feature for the contact list is to blacklist numbers (certain raw IPs or SIP ids - for are authenticated on the cryptomeshes), or to optionally allow only numbers (SIP ids) in the contact list.
When using a cryptomesh, once that is through any corporate/airport/etc firewall, only the local firewall has effect. The IP stays the same regardless of location or clearnet IPs. The cryptomesh IP is a hash or truncated pubkey, and authenticated (unlike telco numbers).
For traditional SIP, there is an authuser and authpasswd that is different from the user part of user@domain. Auththentication is like any federated protocol (eg. XMPP).
Sadly, most “normies” have only used SIP with a telco bridge service, and have no idea that it is actually a federated protocol like email that also works very well fully p2p.
I didn’t vote for Matrix because the encryption part is hard (handling session keys). Apart from that, it is a fairly easy “restful” API. The existing plug-in does ok with unencrypted rooms.