Comment by sneak | Hacker News Reader

Comment by sneak | Hacker News Reader

> specifically the Olm implementation developed by Matrix -- but it should be roughly the same as libsignal

I'm all for "many eyes make bugs shallow", but this is somewhat-widely deployed software, and I have approximately 0% confidence (based on my previous experiences with Mastodon releases and code quality) that this will be strong and safe for its first public release. (Happy to be proven wrong, mind you.)

Perhaps this could be done in an official testing fork, and merged back in when actual cryptographers are more confident about it?

The idea of shipping this in the standard Mastodon release cycle is terrifying, and I really hope they don't intend to do that.

Ultimately, from a design perspective, I'd much rather see ActivityPub implementations support good profile deep linking to existing (read: safe) messengers rather than trying to graft e2e onto a federated messaging protocol that happens to support DMs-do one thing and do it well, and all that. (Also: backwards-compatibility downgrade attacks, anyone?) We all know how well previous attempts at e2e encryption of federated protocols went (spoiler: they didn't).

The modern day version of Zawinski's Law of Software Envelopment seems to be that apps will always attempt to expand until they can send and receive DMs. The consequence of this should not be that every app bundles key generation, key encipherment, key backup, secure key distribution, federated key authentication, and a message cryptosystem simply to support e2e DMs. That's (dangerous) madness.

At the heart of the issue in the complexity of these protocols is that we want to both broadcast widely and address someone specifically. This is a quandary intrinsic to discussion forums, chat rooms and social media.

And the default is to mash both of them together and make it public. Unsurprisingly, it's a source of toxicity and needs intensive moderation, because a broadcasted address is mostly employed in a narrative sense, with the person at the other end reduced to a character in the story. A timeline creates a space, but in a shared timeline, whether it's a Twitter hashtag or a comments section on a small blog, the space is made by spamming your narrative more often.

With a decentralized, privacy-enabled solution like ActivityPub, there are many tools to reshape the extent of the narrative so that you always own your own space, but the tools themselves are quite complex and pressure our engineering and UX capabilities.

And yet - broadcast by itself is not hard, if done in pull-orientation like RSS. And secure messaging is challenging but mostly solved. I have some unfinished thoughts that perhaps simpler is possible by changing the system's orientation further, because I don't think the current designs are quite it.

> A timeline creates a space, but in a shared timeline, whether it's a Twitter hashtag or a comments section on a small blog, the space is made by spamming your narrative more often.

Why isn't this solved fairly easily via a digest metaphor? One can imagine many different implementations, but something as simple as "your recent updates appear in a group and that group can't be bumped to the top of people's feeds more than twice a day" already seems better than the barrage of puke hiccups that is Twitter today.

I agree that any implementation of a new, intended-to-be-secure feature should go through rigorous testing and security review, and that the easiest way to do so is to allow integration with software that already has. However, if you're implementing a Twitter replacement, people expect you to be capable of direct private messaging, with all of the UX considerations that imply—a unified account system, the ability to message everyone already on the platform, having the same look & feel as the original application, etc.

The main benefit of integrated messaging for most users is leveraging the the network effects that come from having a built-in way to message others. This goes away entirely if you have to have every user download a different app and link it and hope that the people they want to talk to will do the same. And the fact of the matter is that "many apps that each do one thing well" is only a good user experience for hackers that can spend a lot of time learning and understanding the quirks of many individual apps, or already have preferences on which apps do what best.

> and I have approximately 0% confidence (based on my previous experiences with Mastodon releases and code quality)

Could you elaborate more on what these problems were? We've had security bugs in the past, but not many more then any other large, complicated app, and to my knowledge we've always fixed them very quickly after they were discovered. We also have a pretty good track record in encouraging adoption of critical security fixes across a large and diverse ecosystem.

> I'd much rather see ActivityPub implementations support good profile deep linking to existing (read: safe) messengers

This is something myself and a few others are interested in pursuing.

Everything for this is in place. No changes or features outside of AP are needed.

Mastodon even has a simple key-value table that any profile can enable and fill with details such as "website: example.com", "twitter: @jack" and so on.

This feature already has "verifications". Meaning that you can add proof that example.com, keybase etc are really yours.

This could easily[1] be expanded to verify ownership of SMS, or messenger apps. Provided those apps have some form or authentication/proof in place.

I have this on our roadmap for our "fediverse linkedin" project (another story for another time) so would gladly offer help here; keybase with my contact details in my hn profile.

-- [1] It would be easy after a refactoring. The code handling this in Mastodon is not ugly persé, but rather unfortunate. Tightly coupled to the God-Model "User" (which seems to happen with every rails project at some point) and spread over some json-store, model and unrelated controllers.

Oops, I think I misunderstood what I was replying to. I see what you mean.

I'm more interested in exploring getting the entire AP ecosystem be encrypted by default, using Chris' work.

I don't think I care that much about profile deep-linking to other apps. I would rather obsolete that need.

Encrypting data meant to be public to the whole web doesn’t make much sense to me.

Have you actually looked at the PR? It's not large and there is very little that actually needs to be done on the server-side. The heavy lifting is offloaded to the client, which will probably further offload its heavy lifting with one of the well-known crypto libraries.

An import 500 modules in the process.

I think you might be exaggerating.

agreed. on random side note, heck there is still no way to delete cached headers, leaving instance storage unbound unless you manually take care of it

Reply on news.ycombinator.com