Big news for the #Fediverse!
General Discussion
36
Posts
14
Posters
77
Views
-
Yeah, you’re not wrong about that. Back in the day, I loved the Trilliam IM client because I could sign in to every IM network from one window.
I’m hoping ActivityPub can become that landline+mobile+sat phone combo on the Internet.
UX will be key, here. Let us cook for a bit, and get some screenshots out to all of you. I’d love to hear your feedback once I have something to show for it.
@benpate @bonfire @swf @sovtechfund
Things I wonder:
- Where will the keys be stored?
- Where will the code come from?I hope none of those will be answered with "browser".
Also, signing in to all messengers in one tool is nice, but what we need is to be able to communicate directly.
It's nice if I can talk to Johne Doe on IRC and Jane Doe on AOL, but what if I want to have a group chat? Yeah. :/
-
@alisynthesis The initial idea is that all fediverse apps (clients and servers) should implement the standard for maximum interoperability. But it's definitely worth thinking about what we could do to make that possible in any case!
@bonfire @alisynthesis Mastodon team will be like: we will add that after at least 20 year
-
@benpate @bonfire @swf @sovtechfund
More ways aren't bad. But those ways should have turns and roundabouts and small footpaths and bridges and maps.
What good is a way that only connects a couple places, but isn't accessible from the rest of the world?
Yes. 💯
That’s why “app builders” like Bonfire and Emissary are so interesting for this space.
We enable the “long tail” of technology adoption, and make it possible for tiny communities to launch highly customized Fediverse apps with very low effort. Small paths, many branches.
AtlasMaps.org (for instance) took me about six weeks start to finish. Other community-specific servers will launch even easier.
😎
-
@benpate @bonfire @swf @sovtechfund I'll read up on what ActivityPub does, but MLS seems like a pretty good start and makes me fear it somewhat less. :-)
Still, we need well thought out interoperability in our FOSS communities. We're more and stronger together.
Jump on the GitHub issues. We’d love to talk.
https://github.com/swicg/activitypub-e2ee
And, I’m happy to walk you through how I’m trying to approach it. We have a tight timeline, but more eyes is still better at this point.
-
@benpate @bonfire @swf @sovtechfund
Things I wonder:
- Where will the keys be stored?
- Where will the code come from?I hope none of those will be answered with "browser".
Also, signing in to all messengers in one tool is nice, but what we need is to be able to communicate directly.
It's nice if I can talk to Johne Doe on IRC and Jane Doe on AOL, but what if I want to have a group chat? Yeah. :/
Keys will be encrypted on the browser, locked with a separate password that’s not shared with the server.
There are some other synchronization issues we’re going to work out, but not before our first sets of code are due.
There’s more here than I can cover in 500char toots. But I’d be happy to chat some time to hear your thoughts
-
RE: https://socialwebfoundation.org/2025/12/19/implementing-encrypted-messaging-over-activitypub/
Big news for the #Fediverse! End-to-end encryption is coming to #ActivityPub.
@swf with support from @sovtechfund is coordinating two interoperable implementations.
Bonfire is proud to be one of these first two projects, alongside #Emissary by @benpate
We think #E2EE should simply be the default for any private communications, and we’re especially thrilled to bring private, trusted collaboration to the fediverse.
-
Keys will be encrypted on the browser, locked with a separate password that’s not shared with the server.
There are some other synchronization issues we’re going to work out, but not before our first sets of code are due.
There’s more here than I can cover in 500char toots. But I’d be happy to chat some time to hear your thoughts
@benpate @bonfire @swf @sovtechfund Another thought before I'll catch up on sleep:
If the code that handles the key material comes from the webserver, that does not stop a government that's hostile from ordering the website owner to run malicious code that'll also encrypt messages for their people... That's what I worry mainly about in terms of security.
-
I am woefully ignorant here. Spare a link for this poor lad?
-
@benpate @bonfire @swf @sovtechfund Another thought before I'll catch up on sleep:
If the code that handles the key material comes from the webserver, that does not stop a government that's hostile from ordering the website owner to run malicious code that'll also encrypt messages for their people... That's what I worry mainly about in terms of security.
Yes. There has to be trust somewhere along the path.
You could host your own server, but you’d still have to trust the developers to not install a back door. Or a supply chain hack. Or…
-
@benpate @bonfire @swf @sovtechfund Another thought before I'll catch up on sleep:
If the code that handles the key material comes from the webserver, that does not stop a government that's hostile from ordering the website owner to run malicious code that'll also encrypt messages for their people... That's what I worry mainly about in terms of security.
One goal is to make this an interoperable standard, so that you could make your own client app, then use your ActivityPub server as only a dumb pipe.
I think that would instill trust.
More in the AM.
-
undefined oblomov@sociale.network shared this topic on
undefined notizie@poliverso.org shared this topic on
-
@bonfire @swf @sovtechfund @benpate Ooof, just another instant messenger..?
We've already had XMPP since the 90s... and since then it's become pretty reliable.
i hope there'll at least be interoperability. I'm so tired of new ways to communicate that are not interoperable with what's already there.
@erebion @bonfire @swf @sovtechfund @benpate @evanprodromou
There is room for more instant messagers:
https://mov.im/blog/debacle/76bf90a4-5f59-4962-92db-6cd859f42ec9
-
Yes. There has to be trust somewhere along the path.
You could host your own server, but you’d still have to trust the developers to not install a back door. Or a supply chain hack. Or…
@benpate @bonfire @swf @sovtechfund The weak point will be wherever you host the webserver. If a court or corrupt official orders them to install something bad, perhaps a backdoor, that is an issue.
-
@benpate @bonfire @swf @sovtechfund The weak point will be wherever you host the webserver. If a court or corrupt official orders them to install something bad, perhaps a backdoor, that is an issue.
Yes, agreed. I know I said this before, but can't find it:
One important goal is to make a solid, consistent client-side API - something like what C2S was intended to be. That would enable interchangeable clients for mobile/desktop/etc that work with any server.. and greatly increase the trust factor.
I'm only good at making web apps, so that's what Emissary's first client will be. But there will be space for others to build on top of this work.
-
@erebion @bonfire @swf @sovtechfund @benpate @evanprodromou
There is room for more instant messagers:
https://mov.im/blog/debacle/76bf90a4-5f59-4962-92db-6cd859f42ec9
I feel like this is the right time to mention https://xkcd.com/927/
You're very right here. There are tons of IM services. "Why introduce another one?" is a reasonable question
But I don't see it in those terms because we're not creating a new network. This is adding features to network we already have
I'll still use Signal. And Apple Messages
And I'd also like to talk privately with people here, as well. There is room for both.
-
RE: https://socialwebfoundation.org/2025/12/19/implementing-encrypted-messaging-over-activitypub/
Big news for the #Fediverse! End-to-end encryption is coming to #ActivityPub.
@swf with support from @sovtechfund is coordinating two interoperable implementations.
Bonfire is proud to be one of these first two projects, alongside #Emissary by @benpate
We think #E2EE should simply be the default for any private communications, and we’re especially thrilled to bring private, trusted collaboration to the fediverse.
-
Our initial clients will be built in JavaScript, so you’d need to enable JS on your browser to use it (for now)
And, it will require special features on your server, so this won’t work on Mastodon (for now)
Download the road, things will change. We’re defining a standard API that anyone can build in. So hopefully someone can built installable clients (iOS, Android, desktop) that work separate from your browser.
-
undefined filobus@sociale.network shared this topic on
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@by_caballero thanks, I’ll have a look!
-
@django https://codeberg.org/socialweb.coop/activitypub-testing this could easily be forked as a starting point
-
@mleduc @saerdnaer @xwikiorg it was amazing when it was alive! Now there is https://ibis.wiki for federated wiki software currently
-
@django They are currently no ActivityPub C2S tests in FediTest. No reason why they could not be added, though, other than the time it takes.
Also, see https://feditest.org/contrib/results/
-
@saerdnaer @liaizon at @xwikiorg we did an activitypub extension https://extensions.xwiki.org/xwiki/bin/view/Extension/ActivityPub%20Application/ for #xwiki, sadly it is not working anymore with other actors of the fediverse and we don't have the bandwidth to revive the extension. But it proved that it was technically possible.
-
-
Random #fosdem notes. Met a nice dev from @ente #ente with whom I discussed a subtle bug on GitHub a few weeks ago (thanks for the now released fix!). Also met @liaizon. Thanks for reaching out; it's always cool to discuss the integration #activitypub in wikis!
-
@j12t digging around l see that there are some some tests relating to client/server relationship
This is all I could find though, is there any documentation of which tests are performed? Or does it follow what the original test suite did?
https://github.com/jernst/annost/tree/08ee6fbe1798bd94883c9cbecbd27fc502409a97
