Mastodon: Add end-to-end encryption API • Hacker News Board

Re: Mastodon: Add end-to-end encryption API

#131

Post by dependenttypes » Tue, May 26, 2020, 2:28 PM UTC

zaarn wrote: post #84

jack1243star wrote: post #64

Earlier quoted context omitted.

If you know about this, you should consider that mastodon.social acts as an example instance. This effectively made blocking Pawoo and a few other instances the norm. There was a block-list circulating around, and if you do not block every instance on the list, your instance is misogynist, pedophile and far-right.

That's simply untrue, speaking as the admin of a smaller instance. There are blocklists but they are entirely up to yourself to implement. I myself only implement rules to completely block far-right instances or "free speech" instances, those tend to cover almost 99% of content that would be frankly illegal for me to federate. The rest is a few japanese and sex-positive instances, which are only media-blocked, so the…

Which one is your instance?

Re: Mastodon: Add end-to-end encryption API

#132

Post by dependenttypes » Tue, May 26, 2020, 2:33 PM UTC

numpad0 wrote: post #17

throwaway1997 wrote: post #13

Earlier quoted context omitted.

I was assuming it was due to the sheer volume of loli being posted on that instance. Most instances block / mute it for this reason.

Anything that isn’t photography is freedom of speech in Japan except genitals so not really

> Anything that isn’t photography is freedom of speech in Japan

There was a lot of censorship during the Fukushima nuclear disaster by the government.

Re: Mastodon: Add end-to-end encryption API

#133

Post by ApolloFortyNine » Tue, May 26, 2020, 2:38 PM UTC

austinheap wrote: post #23

throwawaysea wrote: post #15

What’s the point of Mastodon given the creators are against free speech and for censorship along ideological lines? I don’t see a remaining value proposition for end users.

No one controls Mastodon -- setup an instance and you're off to the races!

The federated Mastodon, the one people generally are talking about, is controlled, by a 'democracy' of sorts of the server owners.

The technology itself is of course open, but if your content is not approved by the main Mastodon federation, then users will have to be signed into multiple Mastodon federations (if that's what they wish), one to see the main Mastodon federation, and one to see the one that got banned. Because of this extra hurdle, a ban from the main Mastodon federation does shut out a large portion of the Mastodon users.

Mastodon is often presented as this 'free speech social network', in reality it's just a decentralized social network, with all the censorship that comes with being a modern social network.

Re: Mastodon: Add end-to-end encryption API

#134

Post by numpad0 » Tue, May 26, 2020, 2:38 PM UTC

dependenttypes wrote: post #132

numpad0 wrote: post #17

Earlier quoted context omitted.

Anything that isn’t photography is freedom of speech in Japan except genitals so not really

> Anything that isn’t photography is freedom of speech in Japan There was a lot of censorship during the Fukushima nuclear disaster by the government.

Never heard of such conspiracy theory before...

Re: Mastodon: Add end-to-end encryption API

#135

Post by dependenttypes » Tue, May 26, 2020, 2:38 PM UTC

vertex-four wrote: post #51

DarkWiiPlayer wrote: post #38

Earlier quoted context omitted.

I had a quick look at mastodon a while ago and saw a few more problems with the model, but I wasn't aware instances could block each other. Maybe some day there will be an even more decentralized alternative (Looking at you, indieweb) where it is up to the user whom they block. I'm also not a huge fan of how mastodon is an implementation, more than a protocol.

I, as a user, am still going to demand that I can join a community where of likeminded people and moderation so I don't have to deal with the overwhelming spam of the internet myself. That's the bit that a number of decentralisation projects don't get - I don't want to have messages by anyone on the whole internet forced into my view (because have you seen how much that sucks?). I want moderation if the day-to-day us…

"where it is up to the user whom they block" does not imply that you have to manually select who to block, rather it could as well mean that you are free to select block-lists (with the ability to fork them if you so wish) of your own choice rather than have the admin of your network force them on you.

Re: Mastodon: Add end-to-end encryption API

#136

Post by arcturus17 » Tue, May 26, 2020, 2:38 PM UTC

joelbluminator wrote: post #116

OkayPhysicist wrote: post #114

Earlier quoted context omitted.

Elixir is, more or less, a thin shell on top of Erlang. As long as Erlang is maintained, Elixir can be pretty easily carried along with, as far as maintaince goes.

How many web developers know Erlang though? this project is mostly web based no?

There’s an entire web framework for Elixir called Phoenix.

You’re painting Elixir as this obscure language that no one knows and while it’s undeniable that it may not be as widespread as JS, PHP or Python, it is not so marginal.

I live in a European city that’s not a tech capital and a couple major startups use it, and I’ve seen it used in major apps across the web.

Never used it myself but read how it excels at concurrency and messaging so why not use it for this?

Re: Mastodon: Add end-to-end encryption API

#137

Post by zaarn » Tue, May 26, 2020, 2:41 PM UTC

dependenttypes wrote: post #131

zaarn wrote: post #84

Earlier quoted context omitted.

That's simply untrue, speaking as the admin of a smaller instance. There are blocklists but they are entirely up to yourself to implement. I myself only implement rules to completely block far-right instances or "free speech" instances, those tend to cover almost 99% of content that would be frankly illegal for me to federate. The rest is a few japanese and sex-positive instances, which are only media-blocked, so the…

Which one is your instance?

It's a fandom based instance hosted in germany, I have about 3000 unique weekly visits according to my backend analytics and around 30 or so MAU.

Re: Mastodon: Add end-to-end encryption API

#138

Post by dependenttypes » Tue, May 26, 2020, 2:43 PM UTC

fenwick67 wrote: post #9

robobro wrote: post #8

Pleroma does what mastodon't

Last I checked Pleroma doesn't even have moderation tools, let alone message franking.

This is incorrect. AdminFE exist.

Re: Mastodon: Add end-to-end encryption API

#139

Post by dependenttypes » Tue, May 26, 2020, 2:45 PM UTC

Hitton wrote: post #79

>An additional layer on top of it is so-called message franking, which allows encrypted messages to be reported to content moderators without compromising keys or message contents ahead of time while also preventing fake reports. That sounds like the encryption isn't deniable. Personally I would prefer deniable encryption to ability to report wrongthink.

> Personally I would prefer deniable encryption

May I ask why? If you are not willing to stand behind something that you said then do not say it at all. Anyway, I do not think that deniable encryption is useful at all, after all potentially edited screenshots are taken as truth all the time. At least if you are using a non-deniable communication method you will be able to ask for proof that you wrote the post which they claim that you wrote.

Re: Mastodon: Add end-to-end encryption API

#140

Post by nightpool » Tue, May 26, 2020, 2:48 PM UTC

sneak wrote: post #2

> 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.) Perhap…

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.