If it helps, any compromises I make or don’t make are irrelevant to anything that will actually happen.
That depends on how much you’re willing to compromise before you see it as wasted effort to participate. Somewhere in the space of ideas there might be a proposal that everyone would accept as an improvement on the status quo.
I don’t think anyone in a position to define LW2.0 is even participating in the threads, though I do hope they’re reading them.
Someone is upvoting your posts besides me. This one is at +19.
I wouldn’t object to that, as long as 1. the specs evolved in tandem, and 2. the gateway was from http/json to (NNTP2?), rather than the other way around.
I meant we could have one spec chapter spec describing types, messages, requests and responses, and then one or more ‘encoding’ chapters describing how these messages are represented in JSON over HTTP, or in… something else. So all encodings would be equal; there could be gateways, but there also could be servers supporting different encodings.
I don’t think this is necessary, but if you insist on non-json/http encodings, it’s probably better to do it this way rather than by translation.
I’m ambivalent about distributed architecture as long as interoperability is maintained.
A distributed system necessarily has fewer features and weaker guarantees or semantics than a non-distributed one. Distributed systems can also be much harder to implement. (NNTP is easy to implement, because it has very few features: messages are immutable, users are not authenticated...) So if you don’t need a true distributed system, you shouldn’t use one.
Mod powers not in the spec seems like a plus to me, not a minus.
As long as comments are stored on private servers, then mods (=admins) can delete them. A spec without mod powers has to store data where no-one but the poster can remove or change it. We’re getting into distributed system design again.
Well, actually, there are ways around that. We could put all comments into a blockchain, which clients would verify, and you can’t retroactively remove a block without clients at least knowing something was removed, and anyone with a copy of the missing block could prove it was the real one. But why?
Today, as I understand it, posts to moderated groups get sent to an email address, which may have whatever moderation software you like behind it.
We’re talking about two different schemes. You’re describing moderated mailing lists; messages need to be approved by mods before other members see them. I’m talking about the LW model: mods can retroactively remove (or, in theory, edit) messages. This too stems from the basic difference between systems with and without mutable messages. In a mailing list or an NNTP group, once clients got their copies of a post, there’s no way for a mod to force them to forget it if they don’t want to.
Users not being tied to a particular server seems like a plus to me too.
By “tied to a server” I mean authentication tied to the DNS name. To authenticate someone as foo@gmail.com using Google login or OpenID or an actual email-based auth system, you talk to gmail.com. The gmail.com admin can manipulate or revoke the foo account. And there’s only one foo@gmail.com around.
Whereas in NNTP, if I understand correctly, I can put any string I like in the From: field. (Just like in classical email.) I might say I’m foo@gmail.com, but NNTP software won’t talk to gmail.com to confirm that.
Someone is upvoting your posts besides me. This one is at +19.
Touche. It’s kind of a shame that Main is out of commission, or I’d be earning a gazillion karma for this.
I meant we could have one spec chapter spec describing types, messages, requests and responses, and then one or more ‘encoding’ chapters describing how these messages are represented in JSON over HTTP, or in… something else.
Hrm. I actually really like this idea; it fits right in with my separate-form-from-function philosophy, and I think standardizing semantics is much more important than standardizing the format of messages over the wire (even though I do have strong preferences about the latter). You’d have to be awfully careful about what went into the spec, though, to allow for a wide range of representations. e.g. if you have a data structure that’s an arbitrarily-nested dictionary, you’re limiting yourself to formats that can represent such a type; otherwise you have the same sort of potential lossage you’d get through a gateway.
But in principle I like it.
[edit: If you were really careful about the spec, you might even be able to get an NNTP-compatible representation “for free”]
Whereas in NNTP, if I understand correctly, I can put any string I like in the From: field.
True with respect to the protocol. I was going to write about this in a future post but maybe it’s better to talk about it now, if only to expose and (hopefully) repair flaws beforehand.
Yes, you can forge From headers, or mod approval headers, or anything really. But the forged message has to enter the network through a server on which you have an account, and that system knows who you are and can refuse to originate messages where the From header doesn’t match the authenticated user. On Usenet this is ineffective; the network is too large. But in a small private network it’s possible for node owners to collectively agree “none of us will allow our users to forge From headers.”
Moderated groups theoretically work like the mailing lists you describe; articles get redirected to a moderation email address. Direct posts are only accepted by the moderator. The address can be (probably is) monitored by software rather than a person, and that software can enforce a policy like “reject posts by users on the Banned list, reject posts with no parent from users not on the Local Sovereign list, accept all other posts.”
As I understand it, cancels and supercedes are also posts in their own right and go through the same moderation queue, so you can extend that policy with “accept cancels or supercedes by the same user as the original post, accept cancels or supercedes by users on the Moderator list, reject all other cancels or supercedes.
I think this works as long as the From header can be trusted—and that, as above, that can be arranged on a closed network (and only on a closed network).
I probably haven’t covered all bases on this; how would you sneak a forged message through such a setup?
In a mailing list or an NNTP group, once clients got their copies of a post, there’s no way for a mod to force them to forget it if they don’t want to.
I consider that a feature, not a bug, but I think I’m misunderstanding you here; no system that permits local caching can prevent clients from keeping old versions of posts around. And web pages are certainly cached (and archived). So I don’t think you mean what it sounds like you mean.
That depends on how much you’re willing to compromise before you see it as wasted effort to participate. Somewhere in the space of ideas there might be a proposal that everyone would accept as an improvement on the status quo.
Someone is upvoting your posts besides me. This one is at +19.
I meant we could have one spec chapter spec describing types, messages, requests and responses, and then one or more ‘encoding’ chapters describing how these messages are represented in JSON over HTTP, or in… something else. So all encodings would be equal; there could be gateways, but there also could be servers supporting different encodings.
I don’t think this is necessary, but if you insist on non-json/http encodings, it’s probably better to do it this way rather than by translation.
A distributed system necessarily has fewer features and weaker guarantees or semantics than a non-distributed one. Distributed systems can also be much harder to implement. (NNTP is easy to implement, because it has very few features: messages are immutable, users are not authenticated...) So if you don’t need a true distributed system, you shouldn’t use one.
As long as comments are stored on private servers, then mods (=admins) can delete them. A spec without mod powers has to store data where no-one but the poster can remove or change it. We’re getting into distributed system design again.
Well, actually, there are ways around that. We could put all comments into a blockchain, which clients would verify, and you can’t retroactively remove a block without clients at least knowing something was removed, and anyone with a copy of the missing block could prove it was the real one. But why?
We’re talking about two different schemes. You’re describing moderated mailing lists; messages need to be approved by mods before other members see them. I’m talking about the LW model: mods can retroactively remove (or, in theory, edit) messages. This too stems from the basic difference between systems with and without mutable messages. In a mailing list or an NNTP group, once clients got their copies of a post, there’s no way for a mod to force them to forget it if they don’t want to.
By “tied to a server” I mean authentication tied to the DNS name. To authenticate someone as foo@gmail.com using Google login or OpenID or an actual email-based auth system, you talk to gmail.com. The gmail.com admin can manipulate or revoke the foo account. And there’s only one foo@gmail.com around.
Whereas in NNTP, if I understand correctly, I can put any string I like in the From: field. (Just like in classical email.) I might say I’m foo@gmail.com, but NNTP software won’t talk to gmail.com to confirm that.
Touche. It’s kind of a shame that Main is out of commission, or I’d be earning a gazillion karma for this.
Hrm. I actually really like this idea; it fits right in with my separate-form-from-function philosophy, and I think standardizing semantics is much more important than standardizing the format of messages over the wire (even though I do have strong preferences about the latter). You’d have to be awfully careful about what went into the spec, though, to allow for a wide range of representations. e.g. if you have a data structure that’s an arbitrarily-nested dictionary, you’re limiting yourself to formats that can represent such a type; otherwise you have the same sort of potential lossage you’d get through a gateway.
But in principle I like it.
[edit: If you were really careful about the spec, you might even be able to get an NNTP-compatible representation “for free”]
True with respect to the protocol. I was going to write about this in a future post but maybe it’s better to talk about it now, if only to expose and (hopefully) repair flaws beforehand.
Yes, you can forge From headers, or mod approval headers, or anything really. But the forged message has to enter the network through a server on which you have an account, and that system knows who you are and can refuse to originate messages where the From header doesn’t match the authenticated user. On Usenet this is ineffective; the network is too large. But in a small private network it’s possible for node owners to collectively agree “none of us will allow our users to forge From headers.”
Moderated groups theoretically work like the mailing lists you describe; articles get redirected to a moderation email address. Direct posts are only accepted by the moderator. The address can be (probably is) monitored by software rather than a person, and that software can enforce a policy like “reject posts by users on the Banned list, reject posts with no parent from users not on the Local Sovereign list, accept all other posts.”
As I understand it, cancels and supercedes are also posts in their own right and go through the same moderation queue, so you can extend that policy with “accept cancels or supercedes by the same user as the original post, accept cancels or supercedes by users on the Moderator list, reject all other cancels or supercedes.
I think this works as long as the From header can be trusted—and that, as above, that can be arranged on a closed network (and only on a closed network).
I probably haven’t covered all bases on this; how would you sneak a forged message through such a setup?
I consider that a feature, not a bug, but I think I’m misunderstanding you here; no system that permits local caching can prevent clients from keeping old versions of posts around. And web pages are certainly cached (and archived). So I don’t think you mean what it sounds like you mean.