We've got a new #ActivityPub implementation that'll be released in early September in #DistributedPress!
Instead of fancy frontends and databases, we're focusing on enabling statically published sites to add AP support via a lightweight Social Inbox server that they can register using standard HTTP Signed Messages.
@mauve sounds cool. More than cool. More like bloody brilliant!
Do you have any thoughts on whether this could work with a p2p architecture?
I've not thought much about it but it was the "here be dragons" part of my getting Solid working with a p2p system. Solid assumes you have a server, whereas I had a storage API and implemented the storage part of the Solid protocol in the client (browser js). It worked brilliantly, enabling Solid apps to run on a p2p system using a subset of the protocol.
@happyborg That's the hope yeah. We're reducing the surface of the bits of AP that need to use a central server as much as possible. Right now the inbox is hosted in the cloud but it could just as easily run on your device and servers could acc3ess it over p2p if they support that or via http gateways.
Similar approach for the published AP data. Initially instances will load over https but we'll be adding specs to include p2p urls for all your data which some clients can load directly.
@mauve
Does that assume connectivity - I mean device and therefore inbox almost always accessible?
Scuttlebutt for example handles intermittent connection but I'm assuming that AP would require high availability.
Ideally a local first (eg CRDT based) inbox could solve this, but I've no idea if that would be feasible.
@happyborg One hard part is how to intoduce yourself to a person for the first time. If you query folloed of followed outboxes for incoming follow requests a la ssb it's not too bad, but when it's a total stranger you need a central randevous point. There's a bunch of approaches but I wrote one up here: https://medium.com/@RangerMauve/p2p-inboxes-be0f02083223