Agreed that both bridging and cross-posting are useful. In practice I think of it more as a continuum than a sharp distinction. Bridged conversations can be less fragmented, but what if Eve and/or Frank aren't bridged? And as @mackuba was jsut discussing on Bluesky, client support is really needed to make bridging smooth as well ... a good example of @laurenshof's point that "ferdation is in the client."

Of course there are similar dynamics with federation, once you take instance blocking and incompatible software into account. In fact when I was experimenting with Discord/Mastodon/NodeBB federation a couple of days ago I was thinking how similar it was to the lossiness of BridgyFed conversations.

I almost wonder if bridging isn't the general way of looking at it, with direct federation over a shared protocol as one special case, cross-posting (automatically, via cliants, or via the low-tech cut-and-paste method) as another, cross-protocol adapers like BridgyFed and Hubzilla as a third.

@quillmatiq @anewsocial @snarfed.org

@thenexusofprivacy @laurenshof @quillmatiq
Smart clients are how we p2p the fedi

Interesting! I like this framing. The parts of that spectrum have useful distinctions, eg incomplete federation due to blocklists etc is often due to policy, and I'm reluctant to call federation via the same protocol "bridging"…but still, definitely a helpful mental model.

Also, more and more, @quillmatiq and I think standardized ways to link accounts and posts across networks/protocols are going to be a critical part of all this, and how different apps etc can interop together across those networks. We have a post on this coming soon! In the meantime: https://fed.brid.gy/docs#identify-bridged-account

(In a discussion on SocialHub, @trwnh asked what kinds of developer-focused discussions were happening elsewhere on fedi and what the barriers were to bringing them to SocialHub. This is certainly a good example! So, as an experiment, I'm going to try tagging @ fediversity @ socialhub.activitypub.rocks to see how that works.*)

I certainly agree about the connections and (where feasible) interop across networks/protocols as being critical. From a terminology perspective it might be better to come up with another term that includes server-based federation (via a same protocol), cross-protocol adapters (server-side connect across protocols), and cross-posting with client support for merging discussions.

* EDIT: it didn't work. In fact it may well. have caused a load spike on SocialHub that made SocialHub unavailable for a few minutes, although it's possible that was just coincidence. In any case I edited this post to remove the tag to keep anybody else from unintentionally also temporarily crashing SocialHub!

@snarfed.org @mackuba @laurenshof @quillmatiq @anewsocial

Here's an interesting situation involving crossposting and sharing the same post that shows how complex things are just with a single profile.

On a post from here (Mastodon) I tagged lemmy.world/c/fediverse (Lemmy) and fediversenews (Friendica). It doesn't rely on me having accounts on the various instances; replies are suppsed to federate to both instances; the implementation did its best to map slightly-incompatible scheme but the title doesn't render well on Lemmy. Is that crossposting, bridging, or federation? In practice the conversation on Mastodon didn't federate to Lemmy, does that change the answer?

Then I used my lemmy.blahaj.zone account to "crosspost" it to piefed.social -- although this is crossposting in the sense of "from one threadiverse community to another" (as opposed to involving multiple accounts on multiple networks).

Fot what it's worth, semantically this seems a lot like a cross-community quote-post with two-way linking; like a quote post or crosspost, the threads and reaction counts (etc) don't get merged -- it would be great to see a merged view of the comments, and that's the kind of thing an app could do. From a user perspective, how different is this from a quote-skeet of a bridged toot or some other situation that does cross protocols? How different is it from the low-tech solution of cut-and-pasting the link (which is what I woud up doing to SocialHub since previous experimenting suggested that tagging the community wouldn't help)?

@snarfed.org @mackuba @laurenshof @quillmatiq

@thenexusofprivacy @snarfed.org @mackuba @quillmatiq

heh yeah very good question on what youd call posting from mastodon to lemmy. dont think theres really a word for it, and dont think simple federation cuts it either considering how functionally broken it is, and how much of a mismatch in UX there is

Yeah. And yet it clearly is federation by most definitions I see.

I don't know, it seems like a general believe that federation (via a shared protocol) is better than bridging. I often see people saying they wish that Bluesky would directly support AP (or fedi would support AT) because a bridged solution is never going to be smooth ... but really the question is whether the various platforms are going to work towards good two-way translation (and sensible fallbacks when models are too different). If not, federation is klunky too. But if they do, why couldn't bridging be smooth?

@laurenshof @snarfed.org @mackuba @quillmatiq

Having run into a few more examples of this with different ActivityPub software, I think there are a couple of distinct things to consider

• the plumbing of communicating between two connecting networks or sites: via a shared protocol ("federation", if it's ActivityPub), via a connector that speaks both protocols (a bridge or hub), via a client, or by a low-tech method like cut-and-paste or export/import

• mapping the semantics and presentation of content across somewhat-0compatble software. With ActivityPub, the standard and agreed-on FEPs provide some basis for this; so do Lexiscons for AT Protocol -- but they don't actually fully solve the problem. When you're mapping across protocols, you don't even have that.

So techniques for cross-protocol mapping are more general, and can also apply to the single-protocol case (and potentially be specialized to take advantage of protocol-specific information). But protocol-specific work doesn't generalize to cross-protocol situations.

@laurenshof @snarfed.org @mackuba @quillmatiq