61–70 of 183 posts
Earlier quoted context omitted.
https://dino.im/
Thanks! Any good Android clients? "Conversations" seems to be the best and it's nowhere near the polish of Signal & Co. crashes often, UX is clunky, family will never stick with it.
I have recently picked up XMPP as my agent communication layer, and its worked great. Each pi agent is given an account and wrapped in an XMPP client[0] that lets it speak to me and other agents when needed. This has worked well since I can spin up new accounts on demand and I can use existing server software (ejabberd, perfect) and clients (Fluux, great; Conversations, okay). I've had to make a few custom modificati…
I have recently picked up XMPP as my agent communication layer, and its worked great. Each pi agent is given an account and wrapped in an XMPP client[0] that lets it speak to me and other agents when needed. This has worked well since I can spin up new accounts on demand and I can use existing server software (ejabberd, perfect) and clients (Fluux, great; Conversations, okay). I've had to make a few custom modificati…
I have recently picked up XMPP as my agent communication layer, and its worked great. Each pi agent is given an account and wrapped in an XMPP client[0] that lets it speak to me and other agents when needed. This has worked well since I can spin up new accounts on demand and I can use existing server software (ejabberd, perfect) and clients (Fluux, great; Conversations, okay). I've had to make a few custom modificati…
Amazing! Perhaps my project here would interest you. Also do you have bonjour support? https://github.com/gatlin/pii
pi-msg doesn't support bonjour, I'm running it on a nixos server (nix is the real secret ingredient of my whole setup) the xmpp server is the same machine as the agents. I'm almost always on a different network to the one where the server is. If the server goes down the agents and ejabberd are coming down simultaneously.
1. Gain/find-someone-with crypto library use knowledge.
2. Jabber client with Iroh networking and E2EE.
3. Completely remove XMPP server dependence.
4. Allow users to exchange Iroh-Node-ID outside of jabber (QR code, other secure channels?), store in Jabber contacts.
5. Develop from there. Calendar usage, multiparty, backups.
But I have neither the time nor the knowhow right now.
I love XMPP and am hopeful for its future with what the teams behind Movim[0], and Fluux[1] are doing. It was a tremendous shame that Matrix didn't improve upon XMPP and instead did their own thing. I continuously wonder what would the XMPP ecosystem look like, if the millions of dollars of funding Matrix initially had (what a waste) went to XMPP instead? [0]: https://movim.eu/ [1]: https://github.com/processone/fluu…
It's sort of the Apache of chat protocols and that's not a compliment.
I love XMPP and am hopeful for its future with what the teams behind Movim[0], and Fluux[1] are doing. It was a tremendous shame that Matrix didn't improve upon XMPP and instead did their own thing. I continuously wonder what would the XMPP ecosystem look like, if the millions of dollars of funding Matrix initially had (what a waste) went to XMPP instead? [0]: https://movim.eu/ [1]: https://github.com/processone/fluu…
It makes sense. It's old, crufty mix of extensions, which nobody actually wants to be that modular for a chat client, because that just gets you into mess of what server/client supports
Working with XMPP gave me a whole new appreciation for why people keep inventing their own chat protocols. I don't think this is an unsalvageable situation, but the protocol is desperately in need of an "XMPP: the Good Parts" doc.
Earlier quoted context omitted.
Matrix is in the same place wrt feature mismatches. It's a quality of the problem, not of the solution. I actually think XMPP does a better, more structured job here.
XMPP leans heavily on capability negotiation and service discovery which makes it straightforward to degrade gracefully when feature mismatches occur. Matrix is significantly lacking in this regard.