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.
@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 Yeah great points. I'm working on a gradual transition timeline where we start at where the current fediverse is and gradually go full p2p.
I think before we replace the current inbox flow we can have more put into indexed outboxes for fast sync so instead of waiting for pushes from the accounts you follow you can get a quick pull for just the data you want and leverage the social graph for loading all that info.
Inboxes do live updates, outboxes are for sync when you come online.
@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
@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.