It's interesting how the creators of the *multi-platform* social client nostr:npub1plstrz6dhu8q4fq0e4rjpxe2fxe5x87y2w6xpm70gh9qh5tt66kqkgkx8j disappeared from Nostr. The last activity I see from the team is in August..

I am more and more convinced that bridging and connecting different protocols in the social sphere doesn't work very well.

Why?

Maintenance becomes exponential - Every protocol has its own update cycles and breaking changes. You're not building one client - you're building several. When one protocol changes, everything breaks.

Lowest common denominator - To work everywhere, bridges strip out what makes each protocol unique. Nostr's zaps, Mastodon's content warnings, Bluesky's feeds - all lost in translation. Users get a watered-down experience.

Identity doesn't translate - Nostr keypairs, ActivityPub domains, and AT Protocol DIDs are fundamentally incompatible. Bridges create confusing mapping layers instead of real unification.

Culture clash - Each protocol has its own norms and expectations. Bridges create an awkward middle ground where nobody feels at home.

Reply to this note

Please Login to reply.

Discussion

nostr:nprofile1qqsdulkdrc5hdf4dktl6taxmsxnasykghdnf32sqmnc7w6km2hhav3g2kyjn9 has been working on DID support for Nostr, which would make any Nostr key pair pluggable into the DID/VC ecosystem.

I just read a blog post regarding the cost of moving social networks, and how Facebook integrated a "backdoor" into MySpace allowing users to migrate more easily back in the day. Mastodon did something similar when people started exit from Twitter, until they stopped it by closing down their APIs.

The bridge with Mastodon that nostr:nprofile1qqsqgc0uhmxycvm5gwvn944c7yfxnnxm0nyh8tt62zhrvtd3xkj8fhggpt7fy built works fairly well, it does increase the amount of content on Nostr.

You're pointing out a major issue though and there is no good solution to the situation.

I might be missing something, but all of these seem like solvable problems. They are mostly data transformation problems, AFAICS.

For example, it seems fairly trivial (especially relative to the payoff of doing so) to map a Bluesky feed to a key pair in Nostr to make it easy to consume that way.

Indeed, this could be a monetisation vector for relays able to offer more advanced interoperability features.

It’s not like the problems of integrating with, say, Twitter, Reddit, or Facebook. There are far more obstacles to that than merely transforming data from one shape into another: violating terms of service, lack of APIs, KYCing, etc.

Yeah it's interesting to look at this in the context of legacy social media: Facebook and X literally *can't* interoperate, not necessarily on any technical level -- although as these platforms are constantly introducing and taking away new features that becomes fraught -- but because of legal and fiduciary issues.

Meanwhile, I think there are certain common "nouns and verbs" to microblogging social media that at least allow for some "floor" of interoperability -- posts, likes, comments, reacts, boosts, quotes, etc -- these things in their basic form are pretty universal.

Obviously Zaps aren't going anywhere outside of Nostr, but signalling an "intention to Zap" could be a powerful way to attract people to the network.

> posts, likes, comments, reacts, boosts, quotes

It sounds simple, but when you think about the details, it's a very complex problem full of problems that you have to solve... for example, when a bridged user quotes a post of a user who is not bridged, and there is dozens or hundreds similar problems.

And whats worst - It usually leads to centralization, that someone has to run those bridges and have the private keys to all those "pseudo" identities. For me, it's just not worth it.

Bridgy Fed on AT Protocol is a typical bridge, connecting Activity Pub and Bluesky. Sure, it's probably a bit useful.... but I also see the danger - that there's one enthusiast who runs it and who now has the power to manipulate all those thousands bridged profiles. Or turn it off, in short, it's all dependent on one intermediary. The complexity of bridging clearly points towards centralization.

>The complexity of bridging clearly points towards centralization.

As it's always been throughout history... The operators of bridges, the original "trolls taking a toll", have always enjoyed this sort of privileged position.

Society responds by (a) building more bridges to compete, or eventually (b) obviating the need for the bridge in the first place by migration to whatever side of the bridge has "greener pastures."

You're missing the most likely option (c) do nothing :)

Actually, Mostr is pretty broken, as I've described: nostr:nevent1qqsdpsmq6zx6aq83p3gs7w2720m9a9l9cuzv9r2s79u00jkkutaxzdspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsyg90jg25kn7sq2fyqvfcdacnxwc2lkt5rgrk7hrn30pxqwjmt8t8rupsgqqqw4rs3snhy6

Agree that this is a pathway to what nostr:nprofile1qqsyk3sjx32e4xs5qj2rtcwapeyrj95yfn4d4h7kkhdgyjc409fmmespr9mhxue69uhhyetvv9ujumt0d4hhxarj9ecxjmnt9urzqpjr has described as "adversiarial interoperability."

Personally I think this is a great way to jumpstart Nostr's growth, but I don't think it's a long-term solution for the reasons nostr:nprofile1qqst9ge7953et4c854glcpp7ctdcke2ml0jf2m4dltdav9dppalp5usppemhxue69uhkummn9ekx7mp0qyfhwumn8ghj7mmxve3ksctfdch8qatz9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcywv3cf describes.

My comment was specifically about bridges and multi-platform clients. That's what I think doesn't work and is a waste of time. One-time migration tools make sense, but that's a little different story for me.

For example, Matrix protocol has a lot of bridges, but that hasn't helped with adoption much. Similarly, on Bluesky, there is Bridgy Fed to connect to Activity Pub, but I don't think that has had any major impact on growth either.

I feel like bridges like this are helping more the larger network become even more dominant, instead of helping smaller networks grow... so maybe it's counterproductive in some way.

> @Melvin Carvalho has been working on DID support for Nostr, which would make any Nostr key pair pluggable into the DID/VC ecosystem.

Do you have any details about that? The fact that Nostr identity will have a DID variant is useless in itself if other protocol (such as the AT Protocol) does not implement it.

Moreover, the idea that you can create a DID variant of Nostr identity and it will be "pluggable" is very naive, ignoring all dependencies, identity is just the tip of the iceberg. Identity (actually the public key) is tied to human-readable identifiers, to profile information, content... and each protocol works completely differently in this.

The bridge are IMHO only meant to be temporary solutions, but they're important ones. Facebook's early success had a lot to do with "bridging" to MySpace.

Eventually there's going to be "one ring to rule them all," and my guess is that's Nostr. But in the interim we can use bridges to communicate with a much broader user base.

Migration is definitely needed and it makes sense. I don't know anything about myspace-facebook, that sounds more like a one way migration. But thats very different from bridges and interop.

Yeah the MySpace thing is something Doctorow brings up a lot, but TBH I have trouble finding sources outside of him.