Comment

Comment by eis

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.

parent eis 4 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton