The metadata is indeed limited since a user does not have a unique global permanent identifier. At most they can track metadata within a single chat room but iirc they even have mitigations for that:

GitHub

simplexmq/protocol/overview-tjr.md at master · simplex-chat/simplexmq

⚙️ SimpleXMQ - A reference implementation of the SimpleX Messaging Protocol for simplex queues over public networks. - simplex-chat/simplexmq

They don't need an identifier, they have both user's IPs/session IDs and channel IDs available. Date/time of messages is also precise. Connecting into multiple friends with the same IP reveals more about you. If the server decides to track (which a court order might require them to) the metadata is probably useful. The beauty of the GiftWrap design is that people can setup their own Inbox relays at will. The package only arrives in the receipient's server, not in the sender's if the person doesnt want to (save a copy locally only). That with random date/times makes it harder for relays to track. Then of course, clients can always use a separate Tor circuit to make sure relays don't receive anything but the message in each connection.

How is it different from setting up your own SMP receiving relay?

Correct me if I am wrong but the SMP contains both user messages. In Nostr each user relay has the peer user messages. Relay can't count the full conversation.

Had to read the above a few times as I'm not very technical. Are you suggesting nostr will be able to provide better privacy compared to SimpleX? How can Nostr hide the metadata? And last question, is something like 0xChat potentially the way?

But aren’t the relays spread across random participants, even some who run servers like Start9’s instead of a centralized company server like Signal uses?

Yep, we hope to do better than SimpleX. The implementation 0xChat and Amethyst have is the same and already this new model :)

GitHub

nips/59.md at fd914c600fd590e6188534cd7555116da7855503 · nostr-protocol/nips

Nostr Implementation Possibilities. Contribute to nostr-protocol/nips development by creating an account on GitHub.

If the relay can't identify the sender how can the relay block senders to protect itself from spam.

Encrypted spam only affects the receiver, who can easily mark as spam just like any other DM.

Brilliant, is there anywhere I can find this explained? Thank you

it also clutters the server (relay). disk space is a scarce resource as much as attention is.

Nostr right now is a small close-knit community like early 90's Usenet. We need to be prepared for an eternal September.

You can have a deal with your users to delete GiftWraps after some time to declutter. But that is between the replay operator and the user. The same clutter can happen with DMs. So this is not an issue of the new method.

Relay monoliths that we have today will never scale to where we are going. None of today's architecture will survive.

🤔

I've looked into it a bit more and can see myself taking advantage of your nip but no common relays or relay implementations really support it right now so will just wait and observe.