XMPP

Quite nice looking new XMPP webclient. Still early days, but might become a Discord replacement in the future.

Of course this also works with a Prosody or Ejabberd xmpp server.

cross-posted from: https://beehaw.org/post/20493770

^ indeed this is cross-posted back to the same community it originated, because slrpnk.net was offline when the post was introduced and Lemmy is not advanced enough to sync caches with original communities.

Email is a non-starter for reasons such as not being in control over who the other party chooses as an email supplier (thus resulting in Microsoft being fed all email traffic).

So snail-mail is the winner. My snail-mail obviously gives a mailing address. From a practical standpoint, that’s all I need. But it would be good to show some kind of electronic means of communication in the letterhead. Not directly for practical use but more of an expression that says “I’m not a luddite but you need to fix your shit” (in so many words).

Requirements:

• must be secure. A low standard of security is fine; it just cannot be so shitty that giant surveillance capitalists can see and exploit the payloads.
• must not rely on any non-standard or proprietary protocols.
• must have at least one FOSS toolchain available.
• must be suitable for documents sent asynchronously.
• ideally a different unique address can be furnished to each recipient.

Candidates:

• XMPP
• onion e-mail (email service by surveillance capitalists cannot send to @*.onion addresses)
• (hypothetical) clearnet email address hosted by a server that blocks inbound MS & Google server connections
• fax number

One problem with the above candidates is I don’t think the 1st two options have any kind of aliasing (I only know of one onion email service that deliberately lacks a clearnet alias, and it does not have aliasing on the userid portion). So I would have to create many accounts and they would never actually get traffic. They would just be symbolic. And the third candidate does not even exist AFAIK.

Problems with the fax number: these are not cheap and I would need a fax number for different countries. Also fax services are gatewayed so some senders send an email to a fax service the dispatches a fax, in which case Microsoft would still see the payload.

Email is a non-starter for reasons such as not being in control over who the other party chooses as an email supplier (thus resulting in Microsoft being fed all email traffic).

So snail-mail is the winner. My snail-mail obviously gives a mailing address. From a practical standpoint, that’s all I need. But it would be good to show some kind of electronic means of communication in the letterhead. Not directly for practical use but more of an expression that says “I’m not a luddite but you need to fix your shit” (in so many words).

Requirements:

• must be secure. A low standard of security is fine; it just cannot be so shitty that giant surveillance capitalists can see and exploit the payloads.
• must not rely on any non-standard or proprietary protocols.
• must have at least one FOSS toolchain available.
• must be suitable for documents sent asynchronously.
• ideally a different unique address can be furnished to each recipient.

Candidates:

• XMPP
• onion e-mail (email service by surveillance capitalists cannot send to @*.onion addresses)
• (hypothetical) clearnet email address hosted by a server that blocks inbound MS & Google server connections
• fax number

One problem with the above candidates is I don’t think the 1st two options have any kind of aliasing (I only know of one onion email service that deliberately lacks a clearnet alias, and it does not have aliasing on the userid portion). So I would have to create many accounts and they would never actually get traffic. They would just be symbolic. And the third candidate does not even exist AFAIK.

Problems with the fax number: these are not cheap and I would need a fax number for different countries. Also fax services are gatewayed so some senders send an email to a fax service the dispatches a fax, in which case Microsoft would still see the payload.

RFC 6350 has a “Security Properties” section which only has a “KEY” field. Public keys tend to be huge; likely too big for a Vcard that will then be encoded as a QR code that needs to fit on a business card. Also too big for a Vcard that would be SMS-transmitted. And it does not take much to throw LaTeX’s QR code package out of bounds:

ERROR: TeX capacity exceeded, sorry [main memory size=5000000]

It would be far more sensible in most cases to include a fingerprint of a public key, which is just a reasonably short hash of the key. But strangely, RFC 6350 seems to only define a field for whole keys. I thought surely I must be missing something. But indeed it’s an oversight. Someone else noticed the problem as well:

https://www.av8n.com/computer/htm/distributing-keys.htm

A fingerprint can probably be stuffed ad hoc into the NOTES field. But without structure it’s not so easy for the person importing the Vcard.

John Denker proposes a reasonable hack for PGP users. But is there nothing for OMEMO fingerprints that an app like #Snikket can make easy use of?

Update

Apparently there is a URI standard format for specifying an OMEMO fingerprint which resembles something like this:

xmpp:user@domain.org?omemo-sid-123456789=A1B2C3D4E5F6G7H8I9…

So although there is no vcard integration, there is at least a way to do a separate QR code.

I have 3 fingerprints (one for each XMPP device) and it would not be ideal to have 3 separate QR codes. This vague bug report seems to suggest multiple fingerprints can be concatinated in a single record.. or is the author requesting that?

The command xmppc -m omemo generates URIs, but it produces a separate record for each fingerprint.

Hello,

I have hosted my own XMPP account and it's really fun, hosting an XMPP server is way easier than hosting an XMPP server which is not a good experience. I also find a lot of public servers of my interest, I guess I will be leaving IRC in favour of XMPP server :)