Notices by Ryan Barrett (snarfed.org@fed.brid.gy)

In practice on the fediverse today, as @raphael says, most fediverse servers do custodial keys. Client-managed keys and signing are still possible though! See @silverpill's FEP-ae97 on client signing. LD Signatures are also relevant; they're not ubiquitous like HTTP Sigs, but still somewhat common, eg Mastodon does them. Also see the SWICG HTTP Sigs report.

cc @Julien51

@tchambers @mackuba @markdarb @mmasnick @mike @hallenbeck @evan @thenexusofprivacy @jaz @chrismessina @bnewbold

Wrote this up: https://snarfed.org/2024-11-01_53932

@tchambers @mackuba @markdarb @mmasnick @mike @hallenbeck @evan @thenexusofprivacy @jaz @chrismessina @bnewbold

Good conversation everyone! Thanks for the support. I'm all for instances and networks making their own decisions on bridge opt-in vs opt-out too.

There's another angle here though: who should make these kinds of decisions on the tools' side, eg for Bridgy Fed itself? And beyond that, if we want to consider defaulting them more toward the opt-out, "big fedi" direction – pardon the metaphor, thanks Evan! – that starts to shift them away from fun useful side projects and more toward core social web infrastructure.

To do that right, they need real structure, organization, and governance. That's at the core of my discomfort so far with considering opt-out. We definitely could put real, grown-up structure in place around Bridgy Fed to turn it into sustainable infrastructure and support that kind of decision. But we (I) haven't yet.

I need to write this up more thoroughly; I'll do that soon. Thanks again for the thoughts so far.

Glad to hear it! @parigotmanchot, more background on the core differences and why Bluesky didn't use AP in eg https://atproto.com/guides/faq#why-not-use-activitypub and https://github.com/bluesky-social/atproto/discussions/1716

@mbajur there's also https://github.com/mastodon/mastodon/issues/22213

It’s been a month since the last Bridgy Fed status update, so it’s time for a new one! I’ve spent a lot of time over the last month on user-visible improvements and bug fixes, notably more complex post types and links, as well as underlying infrastructure. Details below.

One area I need to spend more time on is cost. My attempts at optimization there have been slower than I’d originally hoped. I intentionally prioritized functionality over cost efficiency for a long time, and I’m still optimistic that I can get cost per user down to a reasonable level. If I do that, but user count itself gets too high…that will be a wonderful problem, and I’ll cross that bridge when I get to it. 😁

(Standard disclaimer: Bridgy Fed is non-commercial, free, open source, and ad-free, and I have no plans to change any of that or ask for donations any time soon! It’s one way I try to support and give back to the open social web.)

Beyond cost, I’m hoping to work on native replies and opt in prompts via DM, both directions, soon.

As usual, feel free to ping me with feedback, questions, and bug reports. You can follow the now label on GitHub to see what I’m currently focusing on. See you on the bridge!

• You can disable and delete your bridged account, on either side, by blocking the Bridgy Fed bot user (background). Note that right now this cannot be undone. Maybe eventually!
• Lots of improvements to rich post/profile content and text:
  • quote posts
  • videos and GIFs
  • content warnings
  • link previews
  • hashtags
  • @-mentions (more)
  • profile bios
  • full text of truncated posts and profile bios for third party Bluesky apps like Skythread and Skywalker
  • …and other bug fixes
• Improved authorization/access control checks
• Infrastructural improvements:
  • ATProto PDS XRPC methods and error handling
  • webfinger HTTP status codes
  • firehose client stability
  • firehose server stability
  • better HTTP caching
• Cut new releases of arroba, lexrpc, and dag-json, three libraries of mine that are key building blocks for Bridgy Fed’s Bluesky (AT Protocol) support.

If they did, I'd have to maintain a bunch of different plugins, one for each server I want to support, across all of their different languages and plugin frameworks and APIs, on top with the bridge code itself. Not nearly as feasible as the current plan of integrating at the protocol level, and making the bridge just another instance, and bridged users normal fediverse users, so that users and admins can limit/block both users and the bridge as a whole like normal.

And yes! Bluesky moderation labels are great, I think that framework probably has more long term potential than the fediverse's current instance limit/block approach. @thisismissem is working along similar lines with her FIRES and Fedicheck (for IFTAS) projects.

Moderation labels don't really translate well to hashtags specifically, but the bridge will absolutely support Bluesky labels in general. The Bluesky team's AppView already filters out most of them (including all objectionable ones) by default, and that happens upstream of the bridge.

@GrahamDowns

@timbray

Morning all. Quite a day yesterday, and today so far. I’m obviously taking a beating from everyone who thinks the Bluesky bridge should be opt in. OK.

I want to run one idea by you all. The way the bridge is currently designed, no fediverse profiles or other content are proactively bridged into Bluesky. If someone on Bluesky wants to see or follow someone on the fediverse, they have to manually request it on the bridge. That fediverse user’s posts are then only bridged going forward, and only if someone follows them.

What if, the first time someone on Bluesky requests to follow someone on the fediverse via the bridge, the fediverse user gets prompted, “X from Bluesky wants to follow you. Are you ok with connecting with Bluesky?”, maybe via DM. I assume that would still be considered opt in?

Realistically, most people in the fediverse will never hear about the bridge. Traditional opt in and opt out both generally expect people to proactively find a setting or take some action, often one that only a tiny fraction of people ever learn about. I don’t really care how many people discover or use the bridge, but this kind of just-in-time prompt, only shown when someone wants to follow or interact with them, feels like a useful improvement in that it puts the decision in front of them directly.

Thanks to @kio for the idea. It seems promising; I’m now planning to try it out well before launch. Let me know if you don’t like it.

Bluesky is a broad network with lots of worthwhile people and conversations! I hope you’ll give it a chance. Only fully public content is bridged, not followers-only or otherwise private posts or profiles. Still, if you want to opt out, I understand. Feel free to DM me at @snarfed@indieweb.social (different account than this one), email me, file a GitHub issue, or put #nobridge in your profile bio.

A number of us have thought about this for a while now, we’re committed to making it work well for everyone, and we’re very open to feedback. Thanks for listening. Feel free to share broadly.

Bridgy Fed now supports all web sites! You can now use it from the fediverse to see and follow any site, regardless of whether it has microformats2, webmentions, or WebFinger. Bridgy Fed extracts as much profile info as it can, generates fediverse posts from Atom and RSS feeds, and so on.

Web sites start out bridged to the fediverse as [domain]@web.brid.gy. For example, to see new nature.com articles in your fediverse feed, follow @nature.com@web.brid.gy. And as always, you can upgrade Bridgy Fed to use your web site’s domain in its fediverse handle, like mine at @snarfed.org@snarfed.org.

(I’ve loved seeing other similar bridges recently too, including @twilliability@genart.social‘s RSS Parrot and @dave@podcastindex.social‘s pi-activitypub-server. We’re all pulling in the same direction!)

This is one more step toward making Bridgy Fed support people wherever they are, on any network, fully bidirectionally. Stay tuned for more!

The usual caveat applies: this is in the Bluesky federation sandbox, not prod, until they turn on federation there. Hopefully early next year!

Previously, previously, previously, previously, previously, previously, previously, cc @activitypubblueskybridge@venera.social.