Looks cute - internally it sounds like XMPP rosters if we imagine all mail messages/attachments are pulled too.

Some issues at a glance

• no display names is a good thing - but then “name is retrieved from their public profile” does not sound very good
• ascii for local usernames will probably annoy a lot of people, maybe we should just remove the letters and just issue people numbers (i’m not being sarcastic)
• disallowing IP addresses in the remote part by definition sounds unnecessary

I think there are some gaps on the notification side of things - the agent not being able to verify them (and maybe dropping) or conversely accepting notifications that it should not.

What really puts me off here is the unnecessary use of HTTP .e.g discovery moves from DNS to well known file (webfinger?). Not sure what the benefit is, but ok. And the use of a novel authentication scheme makes me nervous.

It was a nice read and I agree with the point that making this pull based helps. But I wish it did not try to invent so much in one go

Hi. Nice write up. Throwing in my two cents.

I would not kill e-mail, only because it is still one of the few distributed messaging protocols out there which is common. I agree with you about the privacy and security issues - and I think about email as a fully public medium (think public mailing lists and so on). Totally unsuitable for second factor and private (1-1) communication though.

Sadly the only way this will change is if more services accept truly decentralized authentication AND they ALSO can implement moderation and spam control that can work with this. So for those of us on the technical side this means contributing for open source projects (e.g. lemmy, etc) with:

1. authentication back ends for TLS client certificates (if gemini can do it why can’t HTTP? browsers used to support this)
2. good moderation tools to prevent abuse that can work with such authentications - this means avoiding storing state on the service for a “sign up”; it can also mean implementing proof of patience/work e.g. a long time ago there was this for HTTP https://datatracker.ietf.org/doc/html/draft-sporny-http-proofs-01

Getting these two things right is hard work. You have implement somewhat annoying things in your interface like 1) your account only becomes active after X time or after approval 2) proof of work or rate limiting of posts, etc. But ultimately this already happens anyway in current systems, it is just opaque (and based on your IP/email/phone).

On another front, communicating privacy compromises about these things is really hard, imagine drawing a big fluxogram with a rule set for someone to follow

1. talking loudly in public -> e-mail/
2. … (insert your chat medium here - with analogy)
3. for really private conversations 1-1 -> SimpleX
4. everything else is rubbish and we have no idea what they do, assume someone is reading over your shoulder

I think there is one thing that we systematically get wrong - we continue to create tools that do both direct messaging (1-1) and large groups which causes people’s expectations of privacy to be wrong (e.g. end to end encrypted means nothing in a group chat w/ 1000 people and public access).

Finally for fun and laughs, try saying no when someone asks for your email/phone - behave like you have neither. Malicious compliance works wonders with this, give them their number as your number.

PS: I am going to steal this quote of yours “imagine paying to have your privacy disrespected” about phones. Hell I’m making t-shirts and stickers.

This was once common, but it’s somewhat rare now in my experience, and the upcoming Matrix 2.0 apparently addresses most (all?) of the remaining causes.

I still see it - usual case is when someone has two clients. One of them will have issues with this.

I consider this a good thing, for the sake of the people who joined or wrote in the chat with the understanding that what they write is and will remain encrypted. If you want to abandon encryption, you can always create a new room.

Disabling encryption in the room did not have to mean decrypt past history. Yes you can create a new room. But for big groups who wants to risk it. The room admins I know steer clear of encrypted group chats because of the previous issue.

No, there is one officially released client for android: Element. Element X is in beta. When it leaves beta, it will take over as the one officially released client.

One would never guess based on the release announcement

This is just plain false.

https://spec.matrix.org/latest/client-server-api/#sending-encrypted-attachments

The docs say it clearly “If encryption is enabled”. Otherwise attachments are just a link, nothing special there.

Yes and No

I consider matrix to be somewhat equivalent to XMPP or public mailing lists. It is potentially decentralized (even though everyone uses matrix.org) and it can host group chats. And for those purposes it is ok-ish, but for privacy it is no good.

My pet peeve with matrix is that I consider most features to be half baked. And instead of fixing them we just keep pilling up more. Here is a list in no particular order

• encryption regularly breaks in weird ways, usually you see a message that you can’t read
• if you enable encryption in a chat room you cannot disable it
• we now have two official clients for Android (Element and Element X) in the first one encryption breaks in weird ways, in the later there is no way to use Spaces properly
• direct messages between people don’t work well - it is like they are a room with the two people
• privacy wise matrix is weak, leaks metadata, attachments are not encrypted, etc. Do not use if you expect privacy/anonymity. Also I think most groups run without encryption because of the other issues.
• verifying sessions between clients is painful e.g. the client annoys me to verify but then verification does not trigger on the second client

Because of this mess your quality of experience will vary depending on the client and features you use. The web clients are usable.

I don’t really use the video/audio calls so I have no comments on that front.

Just pilling on some concrete examples, awesome-gemini is definitely the best place to start looking. There are both converters for the gemtext format and gateways for the protocols.

For format conversion tools, awesome-gemini already lists a handful of tools.

From the gemini side there are some gateways for specific websites operated by various people

• BBC news gemini://freeshell.de/news/bbc.gmi
• The Guardian gemini://guardian.shit.cx/world/
• Lots of others gemini://gemi.dev/cgi-bin/waffle.cgi

These work pretty well for me. I think there were public gateways to open http pages from gemini, but I can’t recall one from the top of my head.

Some of the gemini browsers support gemini proxies to access http(s) content. You can run it in your own machine. Duckling is the only one I’m familiar (but see the awesome list for more)

• https://github.com/LukeEmmet/duckling-proxy

Conversely, to access gemini pages from a web browser portal.mozz.us hosts a gateway (just place whatever gemini link you want in the box).

One big privacy caveat of using gemini proxies for this is that while this may improve your privacy with regards to javascript/cookies it will reduced it because it makes your behaviour more identifiable from the point of view of the websites you visit (i.e. your proxy is clearly not a browser making it unusual).

Depends on what you mean by “secure”, being very loose with the definitions, we have

• end to end confidentiality (i.e. only you and the intended destination can see the message contents)
• privacy (only the destination knows i’m sending messages to them)
• anonymity (no one can find out who you are, where you live, i.e. metadata/identity/etc)

My personal preference is Simplex.

Reasoning for a few:

• Email: even if you use PGP to encrypt messages the server(s) in the delivery path have access to all metadata (sender, receiver, etc, etc). If no encryption is in use, they see everything. Encryption protocols in e-mail only protect the communication between client and server (or hop by hop for server to server)
• XMPP: similar reasoning to email. i.e. the server knows what you send to who. I should note that XMPP has more options for confidentiality of message content (PGP, OMEMO, others). So I find it preferable to email - but architecturally not too different.
• IRC: Again similar reasoning to email - even if your IRC server supports TLS, there is no end to end encryption to protect message contents. There were some solutions for message encryption/signing, but I’ve never seen them in the wild.
• Signal: Good protocol (privacy, confidentiality, etc). Dependency on phone number is a privacy concern for me. I think there are 3rd party servers/apps without the use of phone numbers.
• Simplex: Probably the strongest privacy protection you can find, but definitely not easy in terms of usability. The assumption is that we do not trust the intermediate server at all (and expose nothing to it), we just leave our encrypted messages there for the receiver to pick up later. It also does some funny stuff like padding messages with garbage.
• Matrix: In theory it supports end to end encryption in various scenarios, but my experience with it has been so bad (UX, broken encrypted sessions) I only use it for public groups.

Some more food for though though; these protocols support both group communication and 1-1 messaging - privacy expectations for these two are very different. For example I don’t care too much about confidentiality in a group chat if there are 3000 people in there. It might be more concerned with concealing my phone/name/metadata.

In general I consider large group chats “public”, I can try to be anonymous, but have no other expectations. e.g. some people use some protocols over ToR because they do not trust the service (or even the destination) but they try to protect their anonymity.

On a technical note: I don’t think there is any protocol that supports multi-device without some kind of vulnerability in the past. So I would temper my expectations if using these protocols across devices.

I’m not familiar with the other ones that were mentioned in comments or in the spreadsheet.

So lets be clear - there is no way to prevent others from crawling your website if they really want to (AI or non AI).

Sure you can put up a robots.txt or reject certain user agents (if you self host) to try and screen the most common crawlers. But as far as your hosting is concerned the crawler for AI is not too different from e.g. the crawler from google that takes piece of content to show on results. You can put a captcha or equivalent to screen non-humans, but this does not work that well and might also prevent search engines from finding your site (which i don’t know if you want?).

I don’t have a solution for the AI problem, as for the “greed” problem, I think most of us poor folks do one of the following:

• github pages (if you don’t like github then codeberg or one of the other software forges that host pages)
• self host your own http server if its not too much of an hassle
• (make backups, yes always backups)

Now for the AI problem, there are no good solutions, but there are funny ones:

• write stories that seem plausible but hold high jinx in there - if there ever was a good reason for being creative it is “I hope AI crawls my story and the night time news reports that the army is now using trained squirrels as paratroopers”
• double speak - if it works for fictional fascist states it works for AI too - replace all uses of word/expression with another, your readers might be slightly confused but such is life
• turn off your web site at certain times of the day, just show a message showing that it only works outside of US work hours or something

I should point out that none of this will make you famous or raise your SEO rank in search results.

PS: can you share your site, now i’m curious about the stories