5 ms·

ActivityPub is built by the W3C and therefore relies on Web related technologies (lost of HTTP and JSON exchanged) :) Does this scale properly and how does it

ActivityPub is built by the W3C and therefore relies on Web related technologies (lost of HTTP and JSON exchanged) :) Does this scale properly and how does it compare to existing solutions like XMPP Pubsub (https://xmpp.org/extensions/xep-0060.html https://xmpp.org/extensions/xep-0060.html) that is basically built to deliver content, in real-time (trough TCP sockets) and can handle thousands (millions?) of delivered packets per seconds? I'm building a federated social platform that is fully relying on XMPP (Movim https://movim.eu https://movim.eu) and I'm wondering about the limits and different usages of this fresh new protocol.

xj9 8y ago
the AP spec is actually, a bit more abstract that you would expect. JSON and JSON-LD are required, but transport and actor resolution are not well specified. current-gen AP servers do have an implicit dependency on HTTP and DNS. i've spoken with several people about creating a proof-of-concept AP server that supports gossip-based replication and a few other ssb-inspired features.
- oelmekki 8y ago
  This sounds interesting. Does it mean an AP server could exist that would not be based on the federation model? Or to make my question more precise : would the gossip model be used only for data distribution and we would still have to register on a node, or would it allow to keep and reuse our data and identity should our usual node disappear?
  - xj9 8y ago
    the goal is to decouple users from servers. the idea is to move the key that AP uses to sign JSON-LD objects to the client and do all of the crypto operations there. a server in this model is an always-on relay for replicating data. you can submit a message to any relay and expect to have it show up on all interested servers. unfortunately, this will also break compat with HTTP/DNS-based AP servers, but hopefully this is something that the maintainers will be open to supporting. relevant threads: https://b.9chan.lol/notice/279590 https://b.9chan.lol/notice/279590 https://b.9chan.lol/notice/226866 https://b.9chan.lol/notice/226866 https://b.9chan.lol/notice/212397 https://b.9chan.lol/notice/212397 https://shitposter.club/notice/9830850 https://shitposter.club/notice/9830850
- defanor 8y ago
  > JSON and JSON-LD are required I find it rather disappointing (in ActivityStreams in general), by the way: on the first sight it's a part of the Semantic Web, but the approaches seem to differ from common ones, and the specification itself mentions that there's merely compatibility with one of the serialization formats (JSON-LD). > but transport and actor resolution are not well specified There's this for ActivityPub though: "Publicly facing content SHOULD use HTTPS URIs", and bits such as "The outbox accepts HTTP POST requests, with behaviour described in Client to Server Interactions", "clients MUST discover the URL of the actor's outbox from their profile and then MUST make an HTTP POST request". Authentication is not specified, but apparently de facto it will be some hacks on top of HTTP, too. Putting those two together, it seems to mostly aim the popular nowadays combination of HTTP and JSON (just RDF/semweb-friendly).
dnomad 8y ago
I suspect XMPP is superior to ActivityPub and the way to go. Bandwidth is only increasing with 5G and with binary XML [1] I think you'll (one day, in theory) be able to get large scale, efficient real-time message flows. XML is just more extensible than JSON soup. These architectures are also probably flawed for pushing for complete N-to-N connectivity. It makes far more sense to push for mobile data that can be liberated from any one server than to assume any given data will always be available and will always provide a given chunk of data. This allows aggregation and caching and copy-resilience which is what makes the web actually work. [1] https://xmpp.org/extensions/xep-0322.html https://xmpp.org/extensions/xep-0322.html
- seanp2k2 8y ago
  XMPP was what I first thought of while reading https://joinmastodon.org/ https://joinmastodon.org/ . My thought before that was "Why will this time be different than that time that ~everyone thought XMPP federation would be the future?"

xj9 8y ago

the AP spec is actually, a bit more abstract that you would expect. JSON and JSON-LD are required, but transport and actor resolution are not well specified. current-gen AP servers do have an implicit dependency on HTTP and DNS. i've spoken with several people about creating a proof-of-concept AP server that supports gossip-based replication and a few other ssb-inspired features.

oelmekki 8y ago
This sounds interesting. Does it mean an AP server could exist that would not be based on the federation model? Or to make my question more precise : would the gossip model be used only for data distribution and we would still have to register on a node, or would it allow to keep and reuse our data and identity should our usual node disappear?
- xj9 8y ago
  the goal is to decouple users from servers. the idea is to move the key that AP uses to sign JSON-LD objects to the client and do all of the crypto operations there. a server in this model is an always-on relay for replicating data. you can submit a message to any relay and expect to have it show up on all interested servers. unfortunately, this will also break compat with HTTP/DNS-based AP servers, but hopefully this is something that the maintainers will be open to supporting. relevant threads: https://b.9chan.lol/notice/279590 https://b.9chan.lol/notice/279590 https://b.9chan.lol/notice/226866 https://b.9chan.lol/notice/226866 https://b.9chan.lol/notice/212397 https://b.9chan.lol/notice/212397 https://shitposter.club/notice/9830850 https://shitposter.club/notice/9830850
defanor 8y ago
> JSON and JSON-LD are required I find it rather disappointing (in ActivityStreams in general), by the way: on the first sight it's a part of the Semantic Web, but the approaches seem to differ from common ones, and the specification itself mentions that there's merely compatibility with one of the serialization formats (JSON-LD). > but transport and actor resolution are not well specified There's this for ActivityPub though: "Publicly facing content SHOULD use HTTPS URIs", and bits such as "The outbox accepts HTTP POST requests, with behaviour described in Client to Server Interactions", "clients MUST discover the URL of the actor's outbox from their profile and then MUST make an HTTP POST request". Authentication is not specified, but apparently de facto it will be some hacks on top of HTTP, too. Putting those two together, it seems to mostly aim the popular nowadays combination of HTTP and JSON (just RDF/semweb-friendly).

dnomad 8y ago

I suspect XMPP is superior to ActivityPub and the way to go. Bandwidth is only increasing with 5G and with binary XML [1] I think you'll (one day, in theory) be able to get large scale, efficient real-time message flows. XML is just more extensible than JSON soup. These architectures are also probably flawed for pushing for complete N-to-N connectivity. It makes far more sense to push for mobile data that can be liberated from any one server than to assume any given data will always be available and will always provide a given chunk of data. This allows aggregation and caching and copy-resilience which is what makes the web actually work. [1] https://xmpp.org/extensions/xep-0322.html https://xmpp.org/extensions/xep-0322.html

seanp2k2 8y ago
XMPP was what I first thought of while reading https://joinmastodon.org/ https://joinmastodon.org/ . My thought before that was "Why will this time be different than that time that ~everyone thought XMPP federation would be the future?"