[HN Gopher] TMTP a Internet protocol combining elements of email...
___________________________________________________________________
TMTP a Internet protocol combining elements of email and the web
Author : modinfo
Score : 67 points
Date : 2022-08-22 12:21 UTC (10 hours ago)
(HTM) web link (mnmnotmail.org)
(TXT) w3m dump (mnmnotmail.org)
| networkimprov wrote:
| Hi, author here, AMA!
| networkimprov wrote:
| FWIW, most of the roadmap for this project is not described on
| the website nor defined in the protocol.
|
| This is a deep topic, and "messaging" is not the only goal, nor
| even the principal one :)
| mxuribe wrote:
| Firstly, i love the recursive nature of the implementaion: "mnm
| is not mail"! Also, quite a fascinating approach; hoping it works
| out! Me being a fanboy of the matrix protocol, I've often
| wondered if there is a valid use-case for matrix to enable safe,
| secure communications between site user/customer, and site
| manager(s). Not just chat, but a sort of customer support
| mechanism, but also a safe, private mechanism for site managers
| and/or orgs to do reasanble outreach to user/customers. And, no,
| it need not be chatbots, though i suppose there would be a desire
| by some orgs for an implementation like that at the end of the
| day. My hope would be of course for a better chatbot than current
| standards. Obviously, there would need to be the delicate balance
| of ease of use, privacy for user/customer, ideally
| decentralization (for empowering liberty/freedoms), integrity of
| content conveyed (by way of non-tampering/security of content),
| etc.
|
| In any case, good luck to the folks behind this effort; the more
| internet protocols (and not centralizied systems/orgs) that can
| help people, the better!
| networkimprov wrote:
| (Author here.) Thanks for your interest & support!
|
| Yes, the default concept for an Internet messaging service is
| "everyone can reach anyone". This isn't helpful for online
| services and businesses who need to reach their
| members/customers directly & securely, and with a rich content
| model (e.g. survey/form in message, and structured result in
| reply).
| cestith wrote:
| Oh, look, we've come full circle to private bulletin boards with
| a custom client.
| vxNsr wrote:
| I don't quite understand how this works. They say it's a new
| protocol but it's still using a browser which would imply it's
| layered on top of UDP or TCP.
|
| Building a new protocol today is kinda like inventing a new
| engine that doesn't require gas, it's gonna need a giant
| motivator to be adopted and trillions of dollars.
|
| The days of grassroots bootstrapping are over, no one has any
| reason to adopt your thing because what we have now is Good
| Enough(tm). Your new thing needs to be revolutionary AND have
| government backing across multiple governments and
| administrations. There is no other way, consider the electric car
| vs hydrogen.
| cestith wrote:
| Most Internet application protocols run on top of UDP or TCP.
| They mean a new application protocol, like SMTP, HTTP, HTTPS,
| L2TP, POP3, IMAP4, SNMP, LDAP, SSH, FTP, RDP, LPD, XMPP,
| Kerberos, remote syslog, etc etc etc. If you're on any flavor
| of Unix, take a look at /etc/services and you'll see there are
| lots of protocols in the world.
| indymike wrote:
| Interesting. The protocol TMT, seems to have the idea of users
| having multiple nodes (which are referred to in comments as
| devices). I suspect if I were to use this in a product, I'd use
| nodes for application instances instead, so if a user had
| multiple apps (i.e. consumer payment app and merchant dashboard
| app) on the same device I could keep them straight. Seems
| promising.
| networkimprov wrote:
| (Author here.) TMTP clients maintain concurrent (possibly
| intermittent) connections to any number of TMTP services, and
| each service gets its own inbox. So you don't need a separate
| app instance per service.
|
| Inboxes for a set of related services could conceivably be
| merged, tho I haven't done any work on that yet.
| indymike wrote:
| Thanks for clarifying.
| sbuk wrote:
| Not sure about the "features" at the end. Specifically Markdown
| support. This is a client-side issue. If MUAs parsed Markdown,
| then there is no reason that markdown couldn't replace html in
| the relevant part of a MIME multipart message. The SMTP server
| only handles ASCII characters; it really doesn't care how that is
| presented. It also afford the possibly of plaintext as a fall
| back. Arguably, you could have all three.
| vidarh wrote:
| It seems to be conflating a communications protocol, an
| application level list management protocol, and parts of a
| message format.
|
| It'd be far more likely to gain support if they unbundled this
| and made it work as an upgrade over e-mail, which would seem to
| make a lot of the spec redundant.
| networkimprov wrote:
| (Author here.) The message format definition is included in the
| protocol doc only as a convenience. Ultimately it would be two
| standards.
|
| Trying to "upgrade" the email ecosystem is an impossible goal,
| and the requirements I'm working to can't be shoehorned into
| the email model.
| towaway15463 wrote:
| The demo is not really usable on mobile. Glad to see efforts to
| build new protocols, I think that's going to be the only way to
| fix the web.
| networkimprov wrote:
| (Author here.) The client UI is designed for desktop. A mobile
| frontend is in the works. Tentatively planning to use Ionic
| Framework with Vue.
| [deleted]
| RajT88 wrote:
| What sites use this?
|
| Seems like Hilton is mostly what comes up when I try searching
| for "sites supporting tmtp"
| duncan-donuts wrote:
| I'm struggling to understand what this actually does. I poked
| around looking for information on the actual protocol, read
| through the site, and I don't understand what this solves. The
| mechanics of the protocol aren't very well defined, and the site
| says a lot of things without giving much information. TMTP isn't
| an idea I would invest in and it's nice that people are working
| on new protocols.
| eis wrote:
| Seems like a poorly thought out protocol. 1.
| Inconsistences like the value for "op" being sometimes integer
| but then sometimes string. Why is this an integer anyways? We are
| already in inefficient JSON land and a lot of the rest is
| strings. 2. No mentioning of ordering or guarantees in the
| draft spec. Bad recommendation to use time for sequential message
| ids. 3. Says E2EE not in it right now but planned. Says
| E2EE not default because sites want to scan and archive messages
| but then the page says email is bad because it doesn't have E2EE
| and nodes can scan messages? 4. The usage of the word
| "node" is confusing and inconsistent. Sometimes it's described as
| a device, sometimes it's a password. "nodeid", "node",
| "newnode"... 5. Seems like one can spoof the alias for each
| message? What's the reason for this? The page specifically
| mentions phishing being an issue with email but wouldn't this
| help phishers? There is no way that I can see if a message came
| from the site itself or a random user on it.
|
| Then a quick look at the code. First noticed the unusual (for Go)
| coding convention like "tFoo" structs, "eErrFoo" errors. Calling
| a mutex "door", weird "//:" comments. I haven't tested it but I'm
| fairly sure the convoluted way of storing user info in flat files
| has path traversal issues. Seems like there's a cache for alias
| -> uid but anyone can pick any alias so they would collide?
|
| Just from a cursory glance. Also doesn't seem like it has moved
| much in a couple years.
| networkimprov wrote:
| (Author here.) Development has been paused for ~1y as I've been
| at work creating a vehicle to take this forward.
|
| The protocol specifics (e.g. identifiers & types) aren't
| polished, because I focused on features in working code. Thanks
| for the feedback!
|
| You can't have alias collisions; it checks whether the string
| you propose is acceptable & available :)
|
| A sender's alias is (or will be) checked against their recorded
| aliases.
|
| The reason why lack of E2EE in email is a serious problem is
| that email traverses at least two "federated" services, which
| are typically third parties with whom you have no intrinsic
| need for a relationship. A TMTP message passes through a single
| service which you explicitly joined.
|
| I don't see how your feedback justifies "poorly thought out";
| it's merely an unpolished preview.
| georgia_peach wrote:
| Wrong place to share. The harmless people here will nitpick
| you to death as the adult version of sucking-up to teacher &
| showing how smart they are. The dangerous ones will silently
| steal the better parts of your idea & run with them, but with
| better funding & connections.
| nominusllc wrote:
| >I don't see how your feedback justifies "poorly thought
| out"; it's merely an unpolished preview.
|
| I don't think they meant this with sincerity. It's
| unpolished, which is accurate, but there's promise there, and
| I think their frustration was the last 20%, which is often
| overlooked- the cohesion of marketing babble and featureset.
| karmakaze wrote:
| > TMTP messages pass through a single service which you
| explicitly joined.
|
| This seems like a product rather than an internet draft
| protocol.
| networkimprov wrote:
| A TMTP client can subscribe to any number of TMTP services
| at different sites.
| karmakaze wrote:
| So in what way is that like email?
| eis wrote:
| Cheers for the reply. > The protocol
| specifics (e.g. identifiers & types) aren't polished, because
| I focused on features in working code. Thanks for the
| feedback!
|
| Got it. IMHO it's better to start with a clean protocol spec
| before implementing features. At least for the very basic
| stuff. Of course for an MVP I wouldn't start with a spec but
| then again this seems past the MVP stage seeing as it started
| 2017 and wants to be a protocol and not just product.
| > You can't have alias collisions; it checks whether the
| string you propose is acceptable & available :)
|
| You can't use a volatile cache to check for collisions
| though. Unless I'm missing something and the "cache" is
| prefilled with all existing aliases somewhere and not
| volatile but then it wouldn't be a cache? Even if it did,
| it's asking for trouble. > A sender's alias
| is (or will be) checked against their recorded aliases.
|
| What about the following: 1. user A adds alias Foo 2. Server
| restarts 3. user B adds alias Foo 3. random other user sends
| message to alias Foo.
|
| My point is a cache should just be used to speed up certain
| operations but has to be handled with care (cache
| invalidation etc). Better to skip this as it's just premature
| optimization and can just cause trouble.
|
| In fact all this work to juggle JSON in flat files will cause
| more headache than it's worth. Just use something like SQLite
| and you'll save yourself a lot of time and issues. It'll make
| the implementation much easier especially to adapt. But it'll
| pay dividends for a long time (migrations etc). You'll run
| into filesystem limitations quite quickly anyways with these
| flat files. > The reason why lack of E2EE in
| email is a serious problem is that email traverses at least
| two "federated" services, which are typically third parties
| with whom you have no intrinsic need for a relationship. A
| TMTP message passes through a single service which you
| explicitly joined.
|
| But what prevents a "gmnm" here? Companies don't want to host
| heir own email servers and they might not want to run their
| own mnm servers. Nothing here guarantees to the user that
| he's directly communicating with the other party. And all
| data is also stored unencrypted.
|
| As GekkePrutser mentioned in a sibling comment, it's 2022 and
| any new messaging protocol without E2EE will be dead on
| arrival. I'm maybe exagerating but it'll have a tough time.
| Especially if it justifies itself partially because email
| doesn't have E2EE. > I don't see how your
| feedback justifies "poorly thought out"; it's merely an
| unpolished preview.
|
| Maybe so. I just saw it mentioning problems with mature
| protocols like SMTP and Matrix and I agree with some of that
| criticism but the solutions are not in TMTP as far as I can
| see. What about synchronization between multiple client
| devices? What about permissions in groups? What about
| identity verifications? What about mobile clients which don't
| want to open dozens persistent connections? There is a long
| list of topics to cover when it comes to messaging protocols.
|
| To create a new protocol isn't an easy task. A protocol
| should be precise and robust. To create a product? Much
| easier.
|
| BTW no one forces people to federate when using Matrix. Or
| one could use something like the Signal protocol. Sure they
| are more complex than TMTP but they have to be because they
| solve a ton of non-trivial issues.
|
| PS: Seems like the demo doesn't actually use the protocol at
| all? It looks like it just loads all static data from
| https://mnmnotmail.org/w/data-demo.js and basically is a
| static page.
| networkimprov wrote:
| Wow, have to ask whether you're interested enough to
| contribute? :) > You can't use a volatile
| cache ... > all this work to juggle JSON in flat
| files
|
| I really don't think I've misused the cache! I didn't use
| SQLite because ordinary admins need to be able to inspect
| and occasionally fix the database. That decision can be
| revisited down the line. > Companies
| don't want to host heir own email servers
|
| TMTP is more like HTTP than SMTP. There must be many ways
| to host a service, just like a website. Any admin must be
| able to bring up a TMTP server. (It's nothing like getting
| a new MTA host to work with the SMTP network!)
|
| I discuss the E2EE issue on the mnm website FAQ. Only
| certain kinds of TMTP sites will want it to be the default.
| If a consumer tech brand offers an online TMTP client, it
| would present a proprietary API to the browser, as Gmail
| does; TMTP can't protect those messages.
| > synchronization between multiple client devices?
| > permissions in groups? > identity verifications?
| > mobile clients which don't want to open dozens persistent
| connections? > the demo doesn't actually use the
| protocol?
|
| Client sync is implemented already \o/ - that's the
| replicas feature. It already has simple, user-defined
| groups. Admin-defined groups is on the roadmap; need user
| input to chart a course here. I've implemented OpenID
| Connect auth for new account registration. It could also be
| required per login, if there's demand. JMAP offers a model
| for how to do non-persistent connections on mobile devices.
| The demo is just the browser-based UI to the client,
| reconfigured to use canned data. (The client is a localhost
| web app.)
|
| And, hey, can't a protocol can be a work in progress? I'm
| only willing to spec what I am ready to implement!
| GekkePrutser wrote:
| Really you shouldn't introduce a new service in 2022 without
| E2EE by default IMO. Not if you want it to be useful going
| forward :)
| Forge36 wrote:
| Previous discussion 208 comments
|
| https://news.ycombinator.com/item?id=25804869
| squarefoot wrote:
| About time someone thought of replacing email protocols with
| something new but without adding the bloat that seems so
| inevitable today. I would also think of integrating functions to
| replace also NNTP (News, USENET), so that it would cover all
| needs between private one to one and public many to many
| communications.
| networkimprov wrote:
| (Author here.) I imagine that existing web-based bulletin
| boards would simply copy messages to TMTP users if requested.
|
| Conversely, TMTP groups/lists could be copied to a read-only
| website.
| myself248 wrote:
| Compare also NNCP: http://www.nncpgo.org/
___________________________________________________________________
(page generated 2022-08-22 23:01 UTC)