Since our last episode, I’ve implemented the client side of ATProto federation in Bridgy Fed. I’m now creating new
did:plcs, inter-service JWTs, and repos on the fly, converting posts to ATProto records, and committing them. I also stood up a serialized hub for serving those local ATProto commits to subscribeRepos subscribers, along with a task queue to propagate them there.
The end result is that I now have a one way, end to end pipeline to receive web and ActivityPub posts and federate them all the way to an ATProto BGS. I’ve tested locally, and it’s working. I’m looking forward to testing against the sandbox!
Next is the other direction. There isn’t yet a subscription XRPC for notifications, so I need to build a dedicated process to poll listNotifications on the AppView. Sigh, ok.
Oh, and I threw together a fun comparison chart of IndieWeb, ActivityPub, ATProto, and Nostr.
@snarfed.org thank you for your work! You are doing important stuff!
Pingback: Last Week in Fediverse – episode 34 – The Fediverse Report
@snarfed.org lovely, thank you so much for [[Bridgy Fed]]!
Any reason you’re using did:plc over did:web? Considering the accounts on the bridge will never (and should never) leave the domain, I would assume did:web is a better fit.
Mainly because Bridgy Fed is more than just web sites! It can and will bridge Bluesky to the fediverse, Nostr, and more.
Oh, you mean did:webs on *.brid.gy itself? True! No good reason except did:plc is clearly more mature and well supported in the Bluesky stack itself, at least at this point, so I trust it more, and it was easy to do. Supporting domain handle resolution took noticeably more work!
Hi all! I finally got another big bit of Bridgy Fed interop working earlier today: bridging Bluesky replies, likes, and reposts into the fediverse. (Only…
Another brief Bridgy Fed progress report: first pass at Bluesky support is feature complete! All basic interactions – user discovery, following, posts, replies, likes, reposts…