4 ms·

2nd-gen email exists in the form of xmpp. Reuse HTML constructs if you dare (https://xmpp.org/extensions/xep-0071.html https://xmpp.org/extensions/xep-0071.html

by rakoo 2y ago

2nd-gen email exists in the form of xmpp. Reuse HTML constructs if you dare (https://xmpp.org/extensions/xep-0071.html https://xmpp.org/extensions/xep-0071.html) or use simpler, safer markup (https://xmpp.org/extensions/xep-0393.html https://xmpp.org/extensions/xep-0393.html). Sign and encrypt with omemo with the assurance it hasn't been mangled with. Use the SRV records registered for it. Define multiple alternative content types if you want (https://xmpp.org/extensions/xep-0481.html https://xmpp.org/extensions/xep-0481.html) It's all there for you to take and improve on without rewriting everything from scratch.

immibis 2y ago
One thing I recently realized is how many protocols are basically the same but ended up in different fields of application by accident. SMTP can transfer arbitrary blocks of text data from a@b to x@y. Usenet can broadcast arbitrary blocks of text data with just a few mandatory headers, so why don't we use NNTP for blogging? You can put mails in your own outbox via IMAP, where the mail server can pick them up and send them. Why don't browsers load HTML via FTP? ActivityPub is basically SMTP if it was JSON (it's so much SMTP that it has a field for 'envelope sender' which was previously thought to be a specific quirk of SMTP), so why don't we use it for email? Or why don't we use SMTP for chatting? Actually, wait, Delta Chat literally does that. Or why don't we use XMPP for email? Or, I don't know, Apache Kafka or Redis. A Kafka server allows you to publish arbitrary messages and stores them until they're retrieved, which is also what a mail server or a chat server does. The only real difference is how authorization works. If you run IRC over Kafka, or IRC over NNTP, you won't lose messages when you disconnect - sounds pretty sensible. Actually what is the difference between NNTP and Apache Kafka, anyway? You get the idea...
- rakoo 2y ago
  Totanly agreed. We as a profession do not learn what existed before, only what the latest are doing and it's tiring. We value creating instead of reusing and maintaining, as seen in the extreme in the evaluation process at Google. We have Show HN for brand new stuff and not Remember HN for past, proven technologies put back to use. As said eloquently by Lu (https://www.todepond.com/ https://www.todepond.com/): NO MORE IDEAS WE HAVE ENOUGH NO MORE TOOLS WE HAVE ENOUGH
  - kwhitefoot 2y ago
    Not many creative technical people want to be mere caretakers of the ideas of the past, however beneficial this might be for the general public.
    - rakoo 2y ago
      Maybe that's the root of the problem. Making technological toys for fun is absolutely ok, but when we pretend to solve people's problems we should probably take a look at old ideas first
AshamedCaptain 2y ago
Ah yes. Which version of OMEMO are you going to use? Almost all Jabber clients (that have had any update in the last 4 years) use different AND INCOMPATIBLE versions of OMEMO. There's the original OMEMO version from the Android client Conversations and the Gnome client Dino, the newer OMEMO:1 which is used by the Windows client UWPX, and the newer OMEMO:2 that is used by the KDE client Kaidan. NONE of the different versions can even talk to each other. I have Jabber clients that talk the protocol from BEFORE it was standarized as XMPP, and they can still talk just fine with a client from this year. However, a client talking OMEMO from 4 years ago cannot talk to a client talking OMEMO from this year. I join the sibling commenter in saying "PLEASE, NO MORE IDEAS WE HAVE ENOUGH".
- MattJ100 2y ago
  > Almost all Jabber clients (that have had any update in the last 4 years) use different AND INCOMPATIBLE versions of OMEMO. This is false. You can see the reality in this data (excuse the URL): https://data.xmpp.net/explore/xmpp?sql=select%0D%0A++software.name%2C%0D%0A++xeps.number+as+xep_num%2C%0D%0A++xeps.title+as+xep_name%2C%0D%0A++xep_version+as+implemented_xep_version%0D%0Afrom%0D%0A++implementations%0D%0A++join+xeps+on+implementations.xep_id+%3D%3D+xeps.id%0D%0A++join+software+on+implementations.software_id+%3D%3D+software.id%0D%0Awhere%0D%0A++xeps.number+%3D+384%0D%0Aorder+by%0D%0A++implemented_xep_version%3B https://data.xmpp.net/explore/xmpp?sql=select%0D%0A++softwar... As you can see, practically all clients are on the same version (0.3). The outliers are UWPX and Kaidan, which both took the unusual decision of being incompatible with the rest of the ecosystem without working on the upgrade path. UWPX is not actively maintained (no releases for a couple of years, and the Github repo is archived). That leaves Kaidan, which is (as far as I know) actively maintained and they deliberately chose to be incompatible with the rest of the ecosystem (for now). I agree it's an unusual choice, but the XMPP ecosystem is diverse and not centralized and nobody can control what people want to do with their time spent working on their open-source projects. EDIT: To clarify some things that are probably non-obvious to people outside the XMPP sphere, the link I gave shows Prosody and Mongoose as supporting OMEMO 0.8.3. They are not clients, but servers - they are compatible with all versions of OMEMO and so are not relevant when it comes to interoperability. And QXmpp is the backend library of Kaidan, by the same developers.

by rakoo 2y ago

immibis 2y ago

One thing I recently realized is how many protocols are basically the same but ended up in different fields of application by accident. SMTP can transfer arbitrary blocks of text data from a@b to x@y. Usenet can broadcast arbitrary blocks of text data with just a few mandatory headers, so why don't we use NNTP for blogging? You can put mails in your own outbox via IMAP, where the mail server can pick them up and send them. Why don't browsers load HTML via FTP? ActivityPub is basically SMTP if it was JSON (it's so much SMTP that it has a field for 'envelope sender' which was previously thought to be a specific quirk of SMTP), so why don't we use it for email? Or why don't we use SMTP for chatting? Actually, wait, Delta Chat literally does that. Or why don't we use XMPP for email? Or, I don't know, Apache Kafka or Redis. A Kafka server allows you to publish arbitrary messages and stores them until they're retrieved, which is also what a mail server or a chat server does. The only real difference is how authorization works. If you run IRC over Kafka, or IRC over NNTP, you won't lose messages when you disconnect - sounds pretty sensible. Actually what is the difference between NNTP and Apache Kafka, anyway? You get the idea...

rakoo 2y ago
Totanly agreed. We as a profession do not learn what existed before, only what the latest are doing and it's tiring. We value creating instead of reusing and maintaining, as seen in the extreme in the evaluation process at Google. We have Show HN for brand new stuff and not Remember HN for past, proven technologies put back to use. As said eloquently by Lu (https://www.todepond.com/ https://www.todepond.com/): NO MORE IDEAS WE HAVE ENOUGH NO MORE TOOLS WE HAVE ENOUGH
- kwhitefoot 2y ago
  Not many creative technical people want to be mere caretakers of the ideas of the past, however beneficial this might be for the general public.
  - rakoo 2y ago
    Maybe that's the root of the problem. Making technological toys for fun is absolutely ok, but when we pretend to solve people's problems we should probably take a look at old ideas first

AshamedCaptain 2y ago

Ah yes. Which version of OMEMO are you going to use? Almost all Jabber clients (that have had any update in the last 4 years) use different AND INCOMPATIBLE versions of OMEMO. There's the original OMEMO version from the Android client Conversations and the Gnome client Dino, the newer OMEMO:1 which is used by the Windows client UWPX, and the newer OMEMO:2 that is used by the KDE client Kaidan. NONE of the different versions can even talk to each other. I have Jabber clients that talk the protocol from BEFORE it was standarized as XMPP, and they can still talk just fine with a client from this year. However, a client talking OMEMO from 4 years ago cannot talk to a client talking OMEMO from this year. I join the sibling commenter in saying "PLEASE, NO MORE IDEAS WE HAVE ENOUGH".

MattJ100 2y ago
> Almost all Jabber clients (that have had any update in the last 4 years) use different AND INCOMPATIBLE versions of OMEMO. This is false. You can see the reality in this data (excuse the URL): https://data.xmpp.net/explore/xmpp?sql=select%0D%0A++software.name%2C%0D%0A++xeps.number+as+xep_num%2C%0D%0A++xeps.title+as+xep_name%2C%0D%0A++xep_version+as+implemented_xep_version%0D%0Afrom%0D%0A++implementations%0D%0A++join+xeps+on+implementations.xep_id+%3D%3D+xeps.id%0D%0A++join+software+on+implementations.software_id+%3D%3D+software.id%0D%0Awhere%0D%0A++xeps.number+%3D+384%0D%0Aorder+by%0D%0A++implemented_xep_version%3B https://data.xmpp.net/explore/xmpp?sql=select%0D%0A++softwar... As you can see, practically all clients are on the same version (0.3). The outliers are UWPX and Kaidan, which both took the unusual decision of being incompatible with the rest of the ecosystem without working on the upgrade path. UWPX is not actively maintained (no releases for a couple of years, and the Github repo is archived). That leaves Kaidan, which is (as far as I know) actively maintained and they deliberately chose to be incompatible with the rest of the ecosystem (for now). I agree it's an unusual choice, but the XMPP ecosystem is diverse and not centralized and nobody can control what people want to do with their time spent working on their open-source projects. EDIT: To clarify some things that are probably non-obvious to people outside the XMPP sphere, the link I gave shows Prosody and Mongoose as supporting OMEMO 0.8.3. They are not clients, but servers - they are compatible with all versions of OMEMO and so are not relevant when it comes to interoperability. And QXmpp is the backend library of Kaidan, by the same developers.