snarfed / bridgy-fed

🌉 A bridge between decentralized social network protocols
https://fed.brid.gy
Creative Commons Zero v1.0 Universal
623 stars 30 forks source link

Bridge DMs/chat #1425

Open snarfed opened 2 days ago

snarfed commented 2 days ago

Bridgy Fed doesn't currently bridge DMs or chat. It could!

Honestly, this is very unlikely. First, the product, UX, and technical needs for chat are pretty different from social networking, which Bridgy Fed is current architected and designed for. Second, for safety and privacy, Bridgy Fed is pretty strictly limited to only bridge fully public content right now, and I'm reluctant to change that.

Still, happy to track the idea here!

Fauli1221 commented 1 day ago

Since dm's are not encrypted to begin with I don't think the privacy issue is that big of an issue maybe make the bot send you a disclaimer dm when you sent the first message

In terms of ux if a dm is a reply to a public post AP -> AT it should probably be fromated:

RE: <link to post>

<text>

From AT -> AP every dm should for simplicity probably be a new message everything else just gets things too complicated

I personally would love to see this feature be realized

Tamschi commented 1 day ago

From AT -> AP every dm should for simplicity probably be a new message everything else just gets things too complicated

At the least it needs to be a reply to the previous message. It would make for very bad UX if the context of the conversation was lost each time.

(That said, this really is a rough transition between ActivityPub and ATProto, since ActivityPub trivially has private group conversations for example, and mentioned-only messages can be contained inside otherwise more public conversations there too.)

voxpelli commented 7 hours ago

When it comes to a standard like Matrix (which I'm no expert on though) I think the main difference from eg. Mastodon-style microblogging is that its about events being posted to rooms / groups rather than being broadcasted from the users own account.

And the way of reading events is to join a room / read them from a room.

So when it comes to "chats" I think one should separate the 1:1 style chats from more open groups / rooms.


Plumbing notes: Groups in Fediverse / IndieWeb

Eg. Lemmy has rooms / groups – they call it "community" – and these are as possible to discover through WebFinger as user accounts are, see eg: https://fedidevs.org/reference/webfinger/#app-lemmy-handle-lemmy_supportlemmyml There they identify it with:

  "properties": {
    "https://www.w3.org/ns/activitystreams#type": "Group"
  }

In the IndieWeb the wiki brings up hashtags as one example of a group-style thing, but I think the best example is how one submits to news.indieweb.org using u-category:

<a href="https://news.indieweb.org/en" class="u-category">#indienews</a>

Plumbing notes: Bridging related aspects about Matrix

On the topic of Matrix: It unlike most other standards have an official standard for bridging: https://spec.matrix.org/v1.12/application-service-api/#third-party-networks / https://spec.matrix.org/v1.12/client-server-api/#third-party-networks

Instant Messaging is also only of plenty of plenty of Modules supported on Matrix: https://spec.matrix.org/v1.12/client-server-api/#modules A microblogging-style module could probably exist eventually, but already when MSC1767: Extensible events in Matrix (accepted in https://github.com/matrix-org/matrix-spec-proposals/pull/1767) is supported one should be able to do something like this to losslessly bridge ActivityPub to Matrix with clients able to progressively enhance to use the full ActivityStreams object:

{
    // irrelevant fields not shown
    "type": "m.message",
    "content": {
        "m.text": [
            { "body": "<i>Hello world</i>", "mimetype": "text/html" },
            { "body": "Hello world" }
        ],
         "org.example.activitystreams": {
            "id": "https://rhiaro.co.uk/2016/05/minimal-activitypub",
            "type": "Article",
            "name": "Minimal ActivityPub update client",
            "content": "Today I finished morph, a client for posting ActivityStreams2...",
        },
    }
}

(What made me think of Matrix in this context was that I got reminded that social networking was an example some had when Matrix was created, and when looking into the functionality of Bluesky it feels like Matrix actually have somewhat of an overlap with it, the concept of a home server is more distinct in both of them whereas Mastodon kind of blurs the concept of community and home server, making the server itself be a kind of community group rather than it being separate from the servers. The IndieWeb kind of follows Bluesky and Matrix as well, but without as much specified about server-to-server relays / aggregation, mainly relying on WebSub and not much more)

Tamschi commented 7 hours ago

The "Group" actor in ActivityPub is somewhat unrelated to chats, it's more a message distribution abstraction. I think some fediverse software may implement it in a way that makes it largely invisible to arrive at a more group-chat-like experience, though.

Conversations in Mastodon don't really have explicit 'membership': Who can view a post is controlled for each post and can broaden or narrow for branches of the same conversation individually. That makes it very difficult to map it into a linear format where there's only one singleton chat/room associated directly with each contact.

voxpelli commented 6 hours ago

The "Group" actor in ActivityPub is somewhat unrelated to chats, it's more a message distribution abstraction.

Eg. a Lemmy community and a Matrix room can be seen as mostly equivalent entities I would say (and both ActivityPub and Matrix are federated event based protocols)

My main point is that it's not necessarily a vast difference between a protocol famous for chat style applications and the kind of protocols that Bridgy already federate with, and that indicates that there is an overlap between "chat"-style setups and existing protocols (but not a 1:1 for all chats and existing protocols)

Here's a project that already builds a bridge between the two: https://gitlab.com/technostructures/kazarma/kazarma

snarfed commented 2 hours ago

Good conversation, thanks everyone!

I don't disagree with any of the plumbing or technical points here. I do want to reiterate a couple non-technical points, though.

First, while you all are right that we can probably translate the data models, interactions, and other details, chat and social networking are still very different products. How people use them, and what they use them for, feel pretty different, at least to me. (The counterargument is DMs and chat that are built into in social networks like the fediverse, Bluesky, etc, of course.)

Second, for as long as I've been building Bridgy classic, and now Fed, I've tried hard to only bridge fully public content. I know it's possible to bridge non-public content, and even do it safely and responsibly, but it would add a significant amount of risk and liability. Personally, right now at least, I'm still not interested in taking on that added risk and liability.

However, if anyone wants to fork Bridgy Fed and try to add DM support, I'd absolutely help! It'd be a nontrivial project, but very doable.

voxpelli commented 2 hours ago

Publicly logged chat rooms / groups that anyone can read the history off – those have the same permission model as the current content in Bridgy Fed.

(A chat room, a Facebook group, a Lemmy community – they mostly differ in what content one can share and both chat rooms and Facebook groups can be either private or public)

I would also keep private stuff out of it.

voxpelli commented 2 hours ago

I do get the point you’re making though – typical chat shouldn’t be in Bridgy Fed, but groups could be, and this issue isn’t about groups explicitly, but chat rooms are a subset of groups and some groups could make sense - eg bridging IndieWeb news to Lemmy or something like that