Post B2xNO8dnxWqMgf1AXI by arcanechat@fosstodon.org
(DIR) More posts by arcanechat@fosstodon.org
(DIR) Post #B2wwZSUbnHaeg9tEHI by rysiek@mstdn.social
2026-02-03T16:19:36Z
0 likes, 2 repeats
#Signal seems to be down, so this is a good moment to consider if you have backup comms channels with people you care about.A Signal Contingency Plan, if you will:https://signal-contingency-plan.info/I agree with the recommendation there and am working on making Delta Chat @delta that kind of backup channel for me and mine.#Resilience
(DIR) Post #B2wwZZxE3HdlowKgM4 by rysiek@mstdn.social
2026-02-03T16:21:26Z
0 likes, 0 repeats
If you're worried about Delta Chat being e-mail based and using OpenPGP, you should probably read this:https://blog.feld.me/posts/2025/03/deltachat-is-actually-good-though/
(DIR) Post #B2wyO4MXMviSYzoN2e by thomaspynching@infosec.exchange
2026-02-03T16:27:09Z
0 likes, 0 repeats
@rysiek @delta I really like Matrix with element. I haven't tried it on a phone, but on a laptop its outstanding.
(DIR) Post #B2wyO5dwbhEaXGxmoS by rysiek@mstdn.social
2026-02-03T16:29:37Z
1 likes, 0 repeats
@thomaspynching not a fan myself.
(DIR) Post #B2wzC1QsXKN7xIf4HQ by davep@infosec.exchange
2026-02-03T16:24:56Z
0 likes, 0 repeats
@rysiek @delta Bugger, it's not even sending messages. Yikes.
(DIR) Post #B2wzC2a8GPMtWHzyLI by rysiek@mstdn.social
2026-02-03T16:26:22Z
0 likes, 0 repeats
@davep I'm sure it's going to come back up sooner rather than later. But it's a good reminder how much we rely on it, and to have a backup plan.
(DIR) Post #B2wzC3KDV4EPpDYmAq by lxo@snac.lx.oliva.nom.br
2026-02-03T16:52:02Z
0 likes, 0 repeats
GNU Jami servers have never gone down on me. how could they? it doesn't need any servers!CC: @davep@infosec.exchange
(DIR) Post #B2wzC7EKyruBw8q8Z6 by davep@infosec.exchange
2026-02-03T16:26:42Z
0 likes, 0 repeats
@rysiek @delta Ok, it is, but very slowly. And I'm not seeing if they got it. DDoS attack?
(DIR) Post #B2xNO7T8JiiH3H18GO by dougwade@mastodon.xyz
2026-02-03T18:03:02Z
0 likes, 0 repeats
@rysiek @delta once e2ee lands on fedi, would that be a reasonable contingency plan?
(DIR) Post #B2xNO8dnxWqMgf1AXI by arcanechat@fosstodon.org
2026-02-03T20:58:49Z
0 likes, 0 repeats
@dougwade Delta Chat would still be a better option, besides being YEARS ahead of such new solution, in Delta Chat you don't depend on a particular server, for example here in fediverse if your instance goes down suddenly you lose your profile, with delta chat you can have several instances at the same time so if one goes down the other keeps working (this is new and still under development), the fedi solution would also need that level of resilience to be comparable @rysiek
(DIR) Post #B2xNO9gg4KjfvrMyeW by dougwade@mastodon.xyz
2026-02-03T21:09:33Z
0 likes, 0 repeats
@arcanechat @rysiek thanks for this thorough answer. Sounds like if I want this someday from the fediverse, it’d be some combination of distributed identity, e2ee, and time, but for today just install delta chat and we’ll worry about all that later.
(DIR) Post #B2xNOANZUr2y4tREVk by feld@friedcheese.us
2026-02-03T21:25:44.238510Z
1 likes, 0 repeats
@dougwade @arcanechat @rysiek I don't want to break your heart but E2EE messaging will never happen on fedi no matter what anyone says, even Soatok himself. (furself?)1. Fedi is accessed by users from multiple clients. So now you have a key synchronization problem that Matrix hasn't been able to get working correctly over the course of... 10 plus years?2. every fedi app that exists which people use will have to updated to support it, and it will NOT be trivial. People are not going to give up their preferred apps just for E2EE messaging.3. every web interface will have to be updated to support it properly. so now we're doing all this crypto in the browser. Your private key will have to live in browser local storage. Not great.4. This of course implies that every fedi server will have to be updated to support it: Mastodon, Pleroma, Akkoma, all the Misskey forks, Lemmy, Pixelfed, Gotosocial.... and this is going to go smoothly without giant security issues happening due to poor implementations right? RIGHT????? :newlol: It's not going to happen.What could happen is that this could become a Mastodon specific feature that only works with Mastodon and the official Mastodon app. Or perhaps there will be a specific e2ee messaging mobile app created that only works with Mastodon. But I doubt it.The biggest problem with this idea is that the entire ecosystem will be so broken/fractured that people will instead choose something else that doesn't have this problem. Whichever is easiest to onboard and doesn't leave you guessing "will they be able to receive my messages?" will win. It will be a dedicated E2EE messaging service such as DeltaChat.The people who keep talking about E2EE coming to fedi are only doing so for clout. They're either dishonest or just stupid and have no idea what it takes to build such an app that will be accessible to the masses.And even if such a thing did exist, it is too easily blocked anyway. Not like it would have helped people in Iran or anything.
(DIR) Post #B2xPV8PnOhaVvCvfJg by mkljczk@pl.fediverse.pl
2026-02-03T21:50:53.752773Z
0 likes, 0 repeats
@feld @dougwade @arcanechat @rysiek 2. and 4. is just ‘we can’t improve just the part of fedi we’re on’. if it was any true, Pleroma would be merely a worse Mastodon clone. there are apps creating new kinds of experiences using ActivityPub and they’re planning to implement the MLS over AP spec. just telling users you can’t use E2EE messaging with some of your friends is much less confusing than the experience mainstream IM users are used to, like whatever recently happened to Facebook Messenger when they switched to E2EE by default
(DIR) Post #B2xQHtFMa6SN4GIWFk by phnt@fluffytail.org
2026-02-03T21:59:15.427871Z
1 likes, 1 repeats
@mkljczk @arcanechat @feld @dougwade @rysiek At least with Pleroma, the chat part has been partly solved. Using classic AP DMs (to: ["https://example.com/users/recipient"] for E2EE isn't undoable without lots of added complexity, because you can add new mentions at least according to how most implementations do it.E2EE over AP is suffering from the Linux case of reinventing the same wheel all over again. Instead of Ciscoware and XML, we have AP/JSON(-LD) and endless extensions, neither work great. Instead of reinventing a protocol never meant for private communications (although never explicitly said) as a simple transport layer, people should have tried to fix XMPP.Here's Pleroma Chat's as they should have been from that start, and I'm not joking that much: https://docs.ejabberd.im/developer/extending-ejabberd/elixir/#embed-ejabberd-in-an-elixir-app
(DIR) Post #B2xQWPl2VGYhx82WZs by phnt@fluffytail.org
2026-02-03T22:02:23.486893Z
0 likes, 1 repeats
@mkljczk @arcanechat @dougwade @feld @rysiek Also I find it funny, that the same topic and same attempts have been popping up for almost 6 years now. I can't stand soatok's blog and I have no idea how long he's been doing it, but lain's blog has a post about exactly this and the problems with E2EE over AP from almost 6 years ago now.https://blog.soykaf.com/post/encryption/
(DIR) Post #B2xSxbrBpJLTCl0nbM by feld@friedcheese.us
2026-02-03T22:19:30.308871Z
0 likes, 0 repeats
@phnt @arcanechat @dougwade @rysiek @mkljczk XMPP sucks the soul out of everyone who dares gaze at it
(DIR) Post #B2xSxci0evb1qZiyvo by phnt@fluffytail.org
2026-02-03T22:29:41.983195Z
0 likes, 1 repeats
@feld @arcanechat @dougwade @rysiek @mkljczk It does, but it also is the closest to an open and extensible ideal messaging platform that currently exists. And it mostly works on the server side. What is not working at all is the client side where 3 different OMEMO versions co-exist, neither of which are compatible with each other and clients seemingly choose which one to implement at random.In some tangential way, it suffers from the same issue as AP always did. Way too extensible to its detriment.I have not looked at the Delta Chat internals yet, but so far after trying to package the relay (probably should continue on that endeavor when I find some inspiration/time), I'm not a fan. If the core is a pile of unportable madness that vendors openssl of all (thanks Rust), it has little hope of surviving long-term. Unless a different implementation(s) (the Golang one's) get more traction than the current reference one.
(DIR) Post #B2xTj2p5Nw9YRte98S by romin@shitposter.world
2026-02-03T22:38:17.539294Z
1 likes, 1 repeats
@phnt @arcanechat @feld @dougwade @rysiek @mkljczk>I want e2ee on my obscure federated microblogging platform- Statements dreamed up by the utterly Deranged
(DIR) Post #B2xTkBLRBdclAVJyHQ by phnt@fluffytail.org
2026-02-03T22:38:26.943460Z
0 likes, 1 repeats
@feld @arcanechat @dougwade @mkljczk @rysiek >that vendors openssl of all (thanks Rust)Apparently that's an optional feature of openssl-sys, so that hopefully isn't enabled.
(DIR) Post #B2xTxufjyIVvVuMhZg by feld@friedcheese.us
2026-02-03T22:38:36.304356Z
1 likes, 0 repeats
@phnt @arcanechat @dougwade @rysiek @mkljczk > I have not looked at the Delta Chat internals yet, but so far after trying to package the relayyou absolutely can package the relay and I did it for FreeBSD but I don't see a point because half of it is based on very specific configuration of multiple services and that's not something that "packaging" alone can solve.Now if you're annoyed about there being so many different services involved, you can look at other work being done in this area. There's a custom version of the Maddy mail server written in Go being worked on (and actively used in a certain country right now) so you can deploy servers with a single binary: https://github.com/themadorg/madmail> If the core is a pile of unportable madness that vendors openssl of all (thanks Rust), it has little hope of surviving long-term.The core as I package it on FreeBSD does not vendor openssl, and the reliance on any openssl at all can likely be removed in the not so distant future
(DIR) Post #B2xUJkv8uNMDdlz7Z2 by phnt@fluffytail.org
2026-02-03T22:44:53.049752Z
0 likes, 1 repeats
@feld @arcanechat @dougwade @rysiek @mkljczk My annoyance with the packaging was more with the configuration being stuck in the debian-specific install tool (at least as of ~2 months ago). I've heard there were improvements on that front I think. The number of services involved was expected since it's email. If you want a normal Dovecot/Postfix setup, you need all of that anyway.Packaging the core wasn't that bad, after packaging a bunch of python dependencies, because I decided to try my chances with packaging it on RHEL8. I think I have it successfully packaged, but I never tried testing it.
(DIR) Post #B2xUQSvYCorbrVNJxI by feld@friedcheese.us
2026-02-03T22:45:58.436465Z
1 likes, 0 repeats
@phnt @arcanechat @dougwade @rysiek @mkljczk if you want an easier to digest version of the relay config/deployment, look at my Chef Cookbook which has re-implemented it all (so I could easily support FreeBSD too)https://github.com/feld/chatmail-cookbook
(DIR) Post #B2xUh2Shr8buhjmnia by feld@friedcheese.us
2026-02-03T22:48:22.077789Z
1 likes, 0 repeats
@phnt @arcanechat @dougwade @rysiek @mkljczk also the python services are being replaced with Rust versions -- filtermail was already done. (inbound/outbound milters for postfix)
(DIR) Post #B2xVgQ6eYsQdhUjvkW by csolisr@hub.azkware.net
2026-02-03T17:23:36Z
0 likes, 0 repeats
@rysiek When you say:But show us a centralized, end-to-end encrypted Signal alternative that is not backed by venture capital, blockchain, the Saudi royal family, or all three, and we'll sell you the Brooklyn Bridge....I remember that XMPP is technically neither of the three - is the reason not to recommend it that end-to-end encryption is an extension for XMPP (OMEMO if I recall correctly), and doesn't come enforced by default by the protocol?
(DIR) Post #B2xVgR72ouKsozvkzw by rysiek@mstdn.social
2026-02-03T18:34:31Z
1 likes, 0 repeats
@csolisr I am not saying it. I am not the author of that website.I had, however, ran several XMPP instances, and figuring out how capabilities of my client, my server, my contact's server and my contact's client mesh together has always been a massive issue.I hope XMPP fixes it one day.
(DIR) Post #B2xZnkPnqreiWzRkLw by dougwade@mastodon.xyz
2026-02-03T23:22:45Z
1 likes, 0 repeats
@phnt @arcanechat @feld @rysiek @mkljczk > we have AP/JSON(-LD) and endless extensions, neither work greatAt the risk of revealing how completely out-of-my-depth I've gotten myself, is there a good explainer on the limitations of JSON-LD you're referring to here?
(DIR) Post #B2xZnlO4EnrTXtdsHo by feld@friedcheese.us
2026-02-03T23:25:06.243994Z
0 likes, 0 repeats
@dougwade @phnt @arcanechat @rysiek @mkljczk I think the real limitation of JSON-LD is that there is no possible way to actually use it effectively. There isn't a database that exists which can handle the schemas.IIRC @sun spent way too much time exploring different new nosql databases trying to make it work, but it just... doesn't.
(DIR) Post #B2xZnmKCkeMkSCqIu8 by sun@shitposter.world
2026-02-03T23:46:20.778793Z
2 likes, 1 repeats
@feld @phnt @arcanechat @dougwade @rysiek @mkljczk the most ideal way to use json-ld is to use expanded form and put it directly in a triple store and make that searchable, but I found it was hard to do this on a FLOSS stack. the triple store space isn't in great shape, you either get expensive proprietary systems or you get poorly documented systems that fall over when you try to CRUD fediverse data at realtime speeds. or sometimes just fall over because they don't work at all, I had multiple projects where release builds just didn't even work right and I had to reach out to developers to find out all the "tricks" to get a working system, terrible bugs, etc.there are other unrelated problems, like you need to have predictable data structure to index and you need indices to make your system work so in practice you have to constrain what you accept.currently I am dealing with the fact that activitypub json-ld documents can have multiple types. in practice I think no system supports this, they just reject documents with an array instead of a string. I extended an activitypub server to support Verifiable Credentials 2.0, and if you want to support Open Badges, it is a hard requirement that the type is ["VerifiableCredential", "OpenBadge"]. So I ended up compromising and internally made our server use heuristics to pick one primary type, and keep supplementary type array for later use. And, internally it only works for non-Activity objects that are the object of an Activity. Hard limitation of the system. Couldn't support full flexibility. Made a compromise. The compromise still is ugly and added annoying complexity to the code. Even if you made a commitment to supporting multiple types, how do you even do that? you can't support it arbitrarily. you can only just hardcode how you deal with specific combinations of types.
(DIR) Post #B2xcqwqeNktLp4DojQ by feld@friedcheese.us
2026-02-04T00:11:52.553234Z
2 likes, 0 repeats
@sun @phnt @arcanechat @dougwade @rysiek @mkljczk so what you're telling me is that it's a spec that was invented with no basis in reality because nothing can actually use this
(DIR) Post #B2xcqyRCTLiqkiKWLA by sun@shitposter.world
2026-02-04T00:20:33.371661Z
3 likes, 1 repeats
@feld @phnt @arcanechat @dougwade @rysiek @mkljczk I have run into situations where it seems literally impossible to make two things that use json-ld interoperate by making the document function for both, which is kind of an explicit promise of json-ld. but, it works a lot of the time, life isn't perfect and if you think about it a bit you realize the promise could never be 100% filled.json-ld works as a substrate for representing a graph of arbitrary-content triple "documents". it is your responsibiliity when you make a real-world system to constrain what you accept.the problem as I see it is that it has no constraints on real-world profiles of usage. its ok at the activitypub level because it is another substrate but if you build something on top of activitypub you should have a spec defining narrowly and rigorously what is valid. so for example if you're building a microblog network you define a microblog interop spec and you also don't pretend it will mesh with for example a subreddit spec or forum spec. you might even make practical constraints like "json-ld allows multiple types but this spec mandates one"
(DIR) Post #B2xdCTCPIUw0Eqf1qi by sun@shitposter.world
2026-02-04T00:24:27.212203Z
2 likes, 1 repeats
@feld @arcanechat @dougwade @mkljczk @phnt @rysiek > json-ld works as a substrate for representing a graph of arbitrary-content triple "documents". it is your responsibiliity when you make a real-world system to constrain what you accept.to clarify this, you could have a system that still lets you have a document representing something that has all kinds of arbitrary data in it. but maybe your system just tracks the graph and a few predictable properties, but lets someone looking up that document by id see any kind of data in there you want, which some other consuming system can handle. json-ld is great for that. you still need to say "it at least has this; it must never have this"
(DIR) Post #B2xeBDjbPPB9wN9iRU by i@declin.eu
2026-02-04T00:35:16.919144Z
2 likes, 0 repeats
@sun @phnt @arcanechat @feld @dougwade @rysiek @mkljczk "but it can triple store" is a total cop out anyway, it's a tarpit on the level of 1 instruction computers, complete by turing and full of crap on all other metrics
(DIR) Post #B2xg3LjXz5FULCVKy0 by neilk@xoxo.zone
2026-02-03T18:08:34Z
0 likes, 0 repeats
@rysiek @delta Your heart may be in the right place here but I beg you to retitle this. It is misleading to call this a “Signal contingency plan”. A proper “Signal contingency plan” would be an outline for how to make my own assessments of my organization’s needs, and then maybe some fallback tools and their various strengths and weaknesses. You are only presenting a kind of Delta advertisement here.
(DIR) Post #B2xg3Mh6Pet5JuMtnM by rysiek@mstdn.social
2026-02-03T18:31:33Z
1 likes, 0 repeats
@neilk since @delta are not selling anything, I don't think it's an ad.I am also very strictly not recommending Delta Chat *over* Signal. Just saying that this is my backup comms channel in case Signal has issues.You are welcome to make your own assessments of your own organization's needs – demanding this, along with "some fallback tools and their various strengths and weaknesses", to be done for you for free by a rando on the Intertubes is a bit rich.
(DIR) Post #B2yKCLs6pv9XXfMB1M by feld@friedcheese.us
2026-02-03T21:26:19.390907Z
0 likes, 0 repeats
@lxo @rysiek @davep You can't send messages over Jami unless the other person is online... which is... kinda useless......
(DIR) Post #B2yKCNBHy65ZbRL0YS by graf@poa.st
2026-02-04T08:26:13.059910Z
0 likes, 0 repeats
@feld @lxo @davep @rysiek @sun Thinking about writing an exclusion policy for domain mutes. feld (and the others in this thread) have blocked poast but I have had genuine and productive discussions with feld in the past. I'm going to work on this tomororw before my road trip
(DIR) Post #B2yMApjr1MltV9toSu by phnt@fluffytail.org
2026-02-04T08:48:20.725398Z
0 likes, 1 repeats
@sun @arcanechat @feld @dougwade @rysiek @mkljczk I couldn't have said it better and I'm not well versed in document parsing and JSON-LD, but I'll add this. The only reason why I mentioned the LD part at first is because it is an entirely optional part of the spec that not many projects use. Contrary to what some say, it is not mandatory at all to use LD. But for something like E2EE you might do things that are more LD-friendly. But if you want schemas (purpose of LD), realistically XML is better at it even though support for XML parsers hasn't been great for the last few years. Which creates an interesting issue. You can remap types in JSON-LD, so you can create a document that has two different meanings to a JSON consumer and a JSON-LD consumer. And the way LD is currently treated isn't by using it properly in a triple store and the usual way you handle documents like this. For the most part, it is handled as pure JSON that is compacted/expanded when processed by a JSON parser with extra logic on top of it. Which of course makes JSON handling a notable performance issue in federation for at least one project and a constant source of issues for the projects.