rrobin

Not sure which docs you are looking at, but my preferred description for this part is SMP

• https://github.com/simplex-chat/simplexmq/blob/stable/protocol/simplex-messaging.md
• https://github.com/simplex-chat/simplexmq/blob/stable/protocol/simplex-messaging.md#smp-procedure

The previous message already pointed out the main point - communication happens via queues our clients knows to belong to the destination, and these queues are temporary. This means even if an attacker determines the queue belongs to a specific person it can be changed and even then it does not reveal who is the other contact using the queue.

A few more bits to consider:

1. queues are unidirectional (so you need at least 2 for a contact) and you only create the ones you use to receive messages
2. the server holds two identifiers for a queue - one for the sender one for the receiver
3. the queue also has two keys - which allow the server to recognize the sender and receiver respectively i.e. only the sender can send and only the receiver can collect msgs (SMP server should reject otherwise)
4. all the keys/ids i mentioned so far a created anew per queue
5. finally the messages that are placed in the queue are encrypted between sender and receiver (DH) but is beyond SMP

So there are IDs but hopefully they are not useful for an attacker.

Now to answer your question. There are IDs but for a message to be delivered to the wrong person the following would need to happen

1. you would have to send it to a server with the wrong ID and encrypted with wrong key
2. the SMP server would need to allow this by decrypting it with the wrong key too (unlikely but not impossible I think - if we assume some magic to break point 3. from before)
3. the message would then be picked up by the receiver (which would try to decrypt it but it would fail)

Caveats - the client app must be well implemented and NEVER reuse keys. Likewise the server must not reuse queue IDs.

I think I got my assumptions right. When in doubt check the 2nd link for a long step by step description of the protocol

I think it is configured in guix-configuration from the guix service type

https://guix.gnu.org/manual/en/html_node/Base-Services.html

there is a tmpdir option there ("A directory path where the guix-daemon will perform builds").

I have not tried this, but something like this on your list of services

(service guix-service-type
  (guix-configuration
    (tmpdir "/whatever")))

As usual for any big changes it is best to try running the operating system spec in a vm with guix system vm to see if it boots up ok.

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

I can't offer a comparison with Session, since I'm not familiar w/ it. At a glance messages seem to be routed through some nodes that belong to a pool of service nodes that run some cryptocurrency stake (but I don't know what this means in practice). It does seem seem to do multi hop routing which means its more resilient to privacy attacks (but this says nothing about resiliency to being blocked).

On the SimpleX side, anyone can operate a SimpleX SMP server - that is the server that holds messages while in transit from the source to the destination (each server has a number of queues, each is one-way from a sender to a receiver ).

Each user defines the servers/queues he uses to receive messages, but not to send (those are the defined by the user you are sending messages to). So resilience to blocking means both users need to diversify the servers they use.

The folks running SimpleX host a handful of servers - and I expect those are the ones most people use. In that sense they are a point of failure for someone to block communication. If you check the source you will see an incomplete list of servers there, and in the app settings there are more (and you can add your own).

As for blocking the protocol, the following approaches seem standard for a state operator:

• block TCP port 5223
• if a different port is used, block based on TLS negotiation - this seems easy to spot
• seize the public servers

(This is as far as my knowledge of SimpleX goes - the rest is slightly hand wavy assumptions I never checked)

I don't recall how the SimpleX app manages those server queue(s?). Taking a peek at the app right I only see one receive/send queue when I select a contact. But in theory it should be possible for it to have multiple queues per contact. The documentation does mention this in some comments (newQueueMsg: maybe it is not implemented?)

• https://github.com/simplex-chat/simplexmq/blob/master/protocol/agent-protocol.md#messages-between-smp-agents

Finally the android app seems to support integration with ToR and will support .onion addresses if this is enabled, that is probably the most practical way to bypass some blocker (assuming ToR is not blocked :D). But this requires that the SMP server used by your contacts supports ToR addresses.

It would definitely be nice to see support for tunneling over other protocols, and of course more servers running those (ToR, I2P, gnunet?, etc, etc).

Some links to stuff:

• Hosting your own SMP Server
• A list of known servers from the source code
• SMP - SimpleX Messaging Protocol
• SimpleX Agent protocol

Thanks for the list, there were a few I did not know about.

I would add ToR and GNUNet (https://www.gnunet.org/) too.

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.

There are gemini to http gateways so the content is probably already crawled anyway.

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

Here is my take as someone who absolutely loves the work simplex did on the SMP protocol, but still does not use SimpleX Chat.

First the trivial stuff:

1. no one else seems to use it
2. UX is not great because of initial exchange

These two are not that unexpected. Any other chat app with E2E security has tricky UX, and SimpleX takes the hard road by not trading off security/privacy for UX. I think this is a plus, but yes it annoys people.

Now for the reasons that really keep me away:

1. the desktop app is way behind the mobile app - and I would really prefer to use a desktop CLI app
2. haskell puts me off a bit - the language is fine I just don't know how to read it - for more practical issues it did not support older (arm6/7) devices which kept lots of people in older devices away
3. AFAIK no alternative implementations of either the client or the SMP server exist - which is a petty I think the protocol would shine in other contexts (like push notifications)
4. I was going to say that there are not many 3rd party user groups - but I just found out about the directory service (shame on me, maybe? can't seem to find groups though)
5. protocol features/stabilization is a moving target and most of the fancy new features don't really interest me (i don't care much about audio/video)
6. stabilization of code/dependencies would help package the server/client in more linux distros, which I think would help adoption among the tech folk

Finally a couple of points on some of the other comments:

• multi device support - no protocol out there can do multi device properly (not signal, none really) so i'm ok with biting the bullet on this
• VC funding is a drag - but I am still thankful that they clearly specified the chat protocol separate from the message relay, which means that even if the chat app dies, SMP could still be used for other stuff.

Depends a bit on what you mean by p2p.

If you mean it as anyone can run their own server - this is already possible. But since message inboxes are one way you can really only control how the server for the messages your are receiving. The messages you send go to wherever the destination says they should go.

If by P2P you mean fully decentralized with no distinction between clients and servers then the discussion is a bit longer, but right now no, and for practical reasons probably not. Let me elaborate a bit.

First the protocol assumes a client, that is your messaging app, delivers the message to a server which is identified by a hostname/ip (you ability to deliver depends on this server being up and working).

For practical reasons the server is a separate entity, just like in email delivery protocols, because

1. it needs a stable hostname or ip address
2. it needs to be reachable most of the time to maximize availability, otherwise messages are not delivered

Now, in practice nothing prevents your client and server from being the same machine, but if the previous two points are not true you will have a bad experience receiving your messages. Specially since most clients are on mobile phones, these two points will likely not be true.

Another thing we could do to get it to be fully distributed would be to run simplex on top of other p2p protocol - anything w/ a DHT that can expose ports to the Internet (Tor, GNUNet, etc). But this has one downside - the client app would need to recognize new types of inbox addresses and connect accordingly.

You could probably achieve this with Tor and some .onion host setup. But then anyone that wanted to deliver to you would need an equivalent setup.

Apologies, I tend to nerd on about distributed systems.

First of all, you can assume the server can infer this in a number of ways - there is actually no way to fully block it, but we can try.

The main issue for privacy is that it makes your browser behave in ways that are a bit too specific (i.e. less private by comparison with the rest of the browsers in the known universe).

As for techniques the site can use

• javascript can test the geometry of something that was rendered to draw conclusions - was this font actually used? test several options and check for variations
• measure font work between network events i.e. generate a site that makes the browser use unique links for 1) fetches a font 2) renders text and 3) only then another fetch - measure the time between 1) and 3) and draw conclusions. Repeat for test cases and draw conclusions - e.g. is the browser really fast using monospace vs custom huge font? not a great method, but not completely worthless
• some techniques can actually do some of this without Javascript, provided you can generate some weird CSS/HTML that conditionally triggers a fetch

By the away not downloading the fonts also makes you "less private". Some of this is a stretch but not impossible.

Now for a more practical problem. Lots of sites use custom fonts for icons. Which means some sites will be very hard to use, because they only display buttons with an icon (actually a letter with a custom font).

FWIW these two lines are in my Firefox profile to disable downloads and skip document provided fonts:

user_pref("gfx.downloadable_fonts.enabled", false);
user_pref("browser.display.use_document_fonts", 0);

If someone has better/different settings please share.

Finally the Tor browser folks did good work on privacy protections over FF. Maybe their issue tracker is a good source of inspiration https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18097

I don't quite agree with some of the rationale

1. I do think users have benefited from Open Source, but I also think that there has been an a decline in Open Source software in general
2. I don't think contracts are a good analogy here (in the sense that every corporate consumer of the software would have to sign one)

Having said this I do understand where he is coming from. And I agree that:

1. a lot of big companies consume this software and don't give back
2. corporate interests are well entrenched in some Open Source projects, and some bad decisions have been made
3. he does raise an interesting point about the commons clause (but them I'm no laywer)

I would like to remind everyone that the GPL pretty much exists because of (1.). If anything we should have more GPL code. In that regard I don't think it failed us. But we rarely see enforced (in court). Frankly most of our code is not that special so please GPL it.

Finally I think users do know about Open Source software indirectly. In the same way they find out their "public" infrastructure has been running without permit or inspection the day things start breaking and the original builder/supplier is long gone and left no trace of how it works.

Since these days everything is software (or black box hardware with firmware) this is increasingly important in public policy. And I do wish we would see public contracts asking for hardware/firmware what some already for software.

I wont get into the Redhat/IBM+CentOS/Fedora or AI points because there is a lot more going on there. Not that he is not right. But I'm kind of fed up with it :D