Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bridge DMs/chat #1425

Open
snarfed opened this issue Oct 25, 2024 · 10 comments
Open

Bridge DMs/chat #1425

snarfed opened this issue Oct 25, 2024 · 10 comments
Labels
feature Features and feature requests that are specific to Bridgy Fed, not fully described by the protocols.

Comments

@snarfed
Copy link
Owner

snarfed commented Oct 25, 2024

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!

@snarfed snarfed added the feature Features and feature requests that are specific to Bridgy Fed, not fully described by the protocols. label Oct 25, 2024
@Fauli1221
Copy link

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
Copy link
Collaborator

Tamschi commented Oct 27, 2024

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
Copy link

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 matrix-org/matrix-spec-proposals#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
Copy link
Collaborator

Tamschi commented Oct 28, 2024

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
Copy link

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
Copy link
Owner Author

snarfed commented Oct 28, 2024

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
Copy link

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
Copy link

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

@snarfed
Copy link
Owner Author

snarfed commented Oct 28, 2024

@voxpelli understood! Groups does seem more likely for Bridgy Fed support. New issue sounds great, feel free to file one!

SWICG is also running a task force on groups aka the "threadiverse" right now, I'll happily follow wherever they end up and read anything they publish on this.

@voxpelli
Copy link

Groups does seem more likely for Bridgy Fed support. New issue sounds great, feel free to file one!

Created a new issue for discussing groups: #1435 Lets move the group discussion there and keep this focused on pure DM/chats 👍 (Mostly a note to myself)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Features and feature requests that are specific to Bridgy Fed, not fully described by the protocols.
Projects
None yet
Development

No branches or pull requests

4 participants