@phryk nice to meet you! Why is 'evil' part of your goals/alignment? Is it tongue in cheek? Otherwise your projects look interesting and resonate with me.
@flancian Also, for my moral alignment refer to my CV at https://phryk.net/upload/file/cv :P
@flancian I was wondering about that agora stuff… Are you communicating directly from it with the agora server just speaking ActivityPub or does it come with its own communication protocol?
@phryk the agora is data-exchange-level primarily: it is a collection of git repos.
We'll have our own protocol if/when more Agoras with compatible contracts come into being, as we'll distribute queries in the network. But that's not implemented yet.
ActivityPub is "spoken" by [[agora bot]] only for now.
The Agora also supports basic RDF exports of any node context using the [[turtle]] action.
@flancian
flancia.org/agora is a 403 and most terms aren't explained, so I'm currently failing to understand what this actually does – but I have to continue work on this XMPP stuff anyways :F
@phryk wow, thanks for catching! I messed up a rule. Fixing :)
I ran the XMPP stack for my employer for a while, but I've now moved to Matrix personally. WDYT of it?
@flancian Of Matrix or XMPP?
@phryk both really if you want to share, but the question was about Matrix (ostensibly the successor?).
@flancian Matrix has most of the features I am looking for in a secure messaging service, but has a few big caveats and I'd never, ever call it the successor to XMPP
Reliance on HTTP seems *extremely* inefficient and I assume is probably the main reason for many of the performance/resource problems I keep hearing about concerning Matrix.
Being discouraged from federating with major instances because it'll eat all your resources just baffles me… I have no idea how this is acceptable.
@flancian The reliance on HTTP makes Matrix polling-based with *every* action resulting in a new connection and yielding a response.
XMPP handles things over a continuous TCP stream, most actions aren't explicitly ACK'd and delivery assurance is handled by TCP itself *as it should be*.
This means no new connection for every action, native "push" capability and better bandwidth efficiency, greatly reducing protocol overhead.
@flancian Also extensibility built into the protocol is a key feature for a long-lived solution.
1) Gradual upgrade routes for clients and servers.
When Matrix publishes a new version of the standard, all existing software is non-compliant until its devs caught up – potentially excluding users of any client not maintained by the Matrix Foundation for months. The situation with servers and federation is even worse.
When a new XEP is released, nobody has to do anything to remain compliant.
2) It makes it way easier to get involved in the standardization to add features – you never have to touch the core spec, implement your featureset and then pour its logic into a descriptive document and submit that as a proposed XEP.
@flancian 3) It makes it way easier to build new software or even completely new implementations of the spec, because the core is so small and lends itself *extremely* well to a modular approach to any involved software.
This also means service operators can pick-and-choose features to reduce resource use or attack surface.
4) It makes deprecating features and substituting them with newer ones easier – for example MUC slowly being deprecated in favor of MIX.
@flancian So, all in all, I'd say XMPP is engineered much better than Matrix.
Also, TIL about the Hotel California Bug – this is exactly the kind of shit that would have been way easier to fix, had Matrix included extensibility at the protocol level.
@phryk thank you, this is a great summary of key differences! Can I include this full thread in the Agora?
@flancian Sure, if you like.
I might make a proper article out of this thread at a later point and will try to remember hitting you up about that, too. :P
