| I don't see anything in your current page that can't be layered into the e-mail model, and my prediction is that this will never get serious traction for that reason, because anything people want from it will just be integrated into e-mail if it starts to get attention. Consider that SMTP was "shoehorned into" the email model, and so was HTML, and attachments. My first e-mail exchange involved UUCP rather than SMTP. For many years my e-mail clients did not understand this newfangled HTML thing. E-mail is extremely malleable because e-mail is extremely simple. Add a "To: " header to a text file and you have a basic e-mail. Copy the file to another machine and you have a mail transport (that's roughly how UUCP worked - by implementing basic file transfer between hosts, and layering distribution of that mail on top with a program that'd read a file of concatenated e-mail messages and distribute them to mailboxes). E-mail is at its core a simple key-value header format, a message body and an address. Everything else is auxiliary. Transport layers can coexist: UUCP coexisted with SMTP for many years. If you invent a new one you just need to decide if you care about having a gateway to let "outsiders" contact you. Message formats can evolve: As long as you provide the basic MIME headers, you're in full control of the format of the message past the first set of headers. You choose how much interop you want by whether or not you use multipart/alternative to provide version readable by "old style" clients. These features are why e-mail in its current form is still around. What you gain* from this is interop and an opportunity to have your system evangelise itself as you use it. To address your page more specifically: >+ choose the sites where you participate
>+ select which members of a site can message you If you enforce DMARC (see below), you can do this in a mail server simply with an option to whitelist domains or users or both. >+ always know from which site a message originated This is supported in e-mail today via DMARC. The reason you still receive e-mail for which it's not the case is lack of universal deployment. You can solve this issue simply by configuring a mail server to reject all e-mail that fails DMARC. > + can block anyone with whom you’ve made contact > + may leave a site and never see traffic from it again If you enforce DMARC, you can certainly block sites at the server level or client level or both, or just block individuals. The upside of doing this with DMARC is that people with it correctly set up will only notice anything different if they try to send you unsolicited messages and get an error message back. > + message formatting & layout via Markdown (aka CommonMark) Solved with client support - just needs the appropriate MIME type set and a ideally a multipart/alternative to deal with any clients that fail to fall back on plain text rendering. > + hyperlinks to messages and other threads Solved with a URN spec and client support. > + hashtags and private tags
> + slide deck layouts
> + data-driven charts & graphs Solved with message formats and MIME types. > + forms/surveys whose results are collected into tables Needs server side support if you want something standardised, but works fine with links to the web today with appropriate client support and HTML, and if you want to provide an upgradeable path it's easily done with client support and a MIME type + requiring multipart alternative w/ a link to a web version for clients without support. So to summarise how I would have done this if I wanted to meet the goals stated on your page: * Pick a mail server that supports JMAP for the client. * Configure it to reject all mail that fails DMARC with a suitable message explaining why. Now you've created pressure to add DMARC for those who don't. * Add a JMAP profile for the client to tell the server if it wants whitelisting or blacklisting, and which users and domains it wants to whitelist and blacklist. I'll tell you right away that most users will reject a whitelisting option, so consider greylisting or quarantine as options. * Optionally define a MIME type to carry subscription/follow/unfollow requests to remote sites, and a DNS record to hold public keys to sign requests. * Define your desired message format and pick a MIME type. * Specify the rendering of a plain text version of the message formats for delivery via multipart/alternative, which includes a footer that specifies that this is a possibly imprecise rendering and links to an info page. Using JMAP means people would be able to connect with any JMAP capable client and "just" lose out on functionality not supported by that client. Using a mail server means most well configured mail servers can already talk to you if whitelisted/not blacklisted. Using multipart/alternative that way means clients can "upgrade" gradually and possibly after users see a link to an info page, and the footer in the plain text parts (or other rendered alternative) would help evangelise the system. |