The point of eating the dog food is not because we like the flavor. The point is to learn from the experience.
On Fri, Sep 9, 2022 at 6:21 AM Maisonneuve, Julien (Nokia - FR/Paris-Saclay) <julien.maisonneuve@xxxxxxxxx> wrote:\
...
But the biggest hurdle were the jabber accounts, with servers disappearing or just not working
...
This is the single biggest problem with any new messaging or communications infrastructure. And it is fixable. Or at least I have a fix.
Alice gets an account alice@xxxxxxxxxxx, example.com shutters its service, Alice has to find a new provider.
It is a problem in SMTP email as well as Jabber. But not so much for the email service provider who regards it as 'customer retention'.
My solution is to use cryptography to create an account for Alice that belongs to Alice alone, does not depend on her choice of service provider and can be used as an 'account for life'. This is of course tied to a root of trust that is a public signature key (Ed448 + Dilithium5).
So having provisioned Alice with an account for life, we can then bind it to multiple account addresses as the fancy takes Alice. She can be alice@xxxxxxxxxxx and also alic3@xxxxxxxxxxx for her leet convos. And she can move to example.net without issue. The callsign registry if deployed would allow her to be just @alice and never pay a renewal fee.
When Alice exchanges contacts with Bob, they exchange signed contact data that can include an 'update' URI. So if Alice switches her Jabber provider, Bob can still reach her. Same for if Alice switches protocols.
So my vision for the contact catalog is that it becomes the launch center for all of Alice's communications apps. All Alice does is to select the person she wants to reach and the communication mode (chat, voice, video...). And the contacts app hands off to whatever app handles that for that particular contact.
It is of course exactly the same scheme that Dan Connoly invented back in the day which we now know as the URI scheme identifier. And that is how I plan to implement it.
scheme:user@authority:credential
Aggressive interop: If a messaging provider doesn't specify a URI, one will be specified for them. While there are dozens and dozens of walled gardens, there are actually only a handful of actual protocols in use. Most people are using xmpp or noise underneath. I doubt anyone is using anything other than WebRTC for voice and video at this point.
I have been seriously considering using XMPP for presence service and rejected it because I think we need to look at presence in a whole different way. If an application is going to have to maintain some constant connection to a static IP service in the routable Internet, I am going to leverage that to the hilt and use it for everything. I am going to use it for my TURN and DNS client-resolver and everything else I can think of. And then having compressed all of my signal into one channel, I can use TOR type techniques to resist traffic analysis in cases where that is appropriate.
My problem with using Jabber at IETF was real, I do not have cause to use it outside IETF because all my other conversations take place over always secure channels. Retrofitting security to legacy protocols only worked once and that was HTTPS and it took over 20 years.
So multiple IETFs, I would arrive with a laptop with either no jabber client or a jabber client trying to use a IDP that has shuttered. So I realize I need the client at the start of my first meeting. First spend time searching for the app for that machine, install, ok now 10 mins in. Then I have to futz about logging into the IETF meeting using an account at a completely different freaking service and for what? Why do I even need to authenticate as hallam@xxxxxxxxx to connect to a public meeting on the IETF service?
So thirty minutes into the meeting I am still futzing with the Jabber client, now I am looking for a new IDP provider. And the first couple I tried are no longer in business either.
By 45 minutes in, I give up and I don't try to use Jabber again for another year. We can't go on like this: No, it's not me, it's you.
The only way I could possibly expect jabber to work the way I want it to is to run my own service. And I rather suspect that is what most people do. And I know that I could easily set up a service on my Digital Ocean droplet and solve MY problem, but in the process I have cut myself off from understanding what the typical user is experiencing.
