6 ms·
“Pest” vs. 0xFE
- hermitdev 5y agoTitle should be updated to match the original: "Pest" v. 0xFE "vs." being an abbreviation for versus carries an entirely different meaning than the intended version.
- saurik 5y agoFWIW, I would have read "v." the same, as "v." is also an abbreviation--mostly used in legal documents and court cases--for versus.
- kazinator 5y agoLooks like the versions count down toward zero. Pest v. 0xFF is an older article by several days.
- asciilifeform 5y agoThis is correct, and is described in the article ("Kelvin versioning".) The concept is not original to the author.
- unwind 5y agoIt's supposed to mean "version"? The post seems to be the successor/continuation of "Pest v. 0xFF", replacing it by ... decreasing the version number? Then it starts off saying that you're going to need a "vtree", and for that obviously you need a "V-tron" and that's about where I gave up. It was like trying to read something from a parallel world.
- nerdponx 5y agoApparently this is something related to using the Bitcoin blockchain to produce a cryptographically verifiable sequence/tree/dag(?) of revisions. Like Git but more crypto-ey.
- asciilifeform 5y ago"V" is a very simple versioned publication system (there's an explanatory link in the article.) Vpatches are backwards-compatible with ordinary gnupatch. (can simply execute "patch -p0 < nameofpatch" for the sequence.) "V" has nothing directly to do with Bitcoin.
- dafoex 5y agoIn all brutal honesty I would have read "v." as versus, whereas just "v" as in "v 4.2.0" would be version.
- lixtra 5y ago> 1.1. What is Pest? > Pest is a peer-to-peer network protocol intended for IRC-style chat. It is designed for decentralization of control, resistance to natural and artificial interference, and fits-in-head mechanical simplicity -- in that order. > Pest explicitly rejects the inherently-centralizing concepts of IRC
- nerdponx 5y ago> 1.2.1. One Station -- One Operator. > An IRC server is typically inhabited by a multitude of casual users and policed by a small group of privileged curators. A Pest station, on the other hand, is under the exclusive control of one person: its operator. > 1.2.2. Nets Instead of Channels. > Pest stations organize into nets. A net is formed by a group of station operators with a common interest. An operator who wishes to join a net must peer with at least one of the stations in that net. A broadcast message is sent to every member of a station's net. Nets may easily and organically undergo schismatic splits, or, on the contrary, combine into larger nets, whenever the individual station operators so desire. This is interesting stuff. The basic model seems kind of elegant and should be relatively straightforward to implement. It also seems like it should be relatively easy to set up a station that "bridges" to other chat platforms like Matrix, IRC, etc. However I suspect that moderation being nonexistent could pose a problem. Un-peering with somebody is equivalent to blocking them, which is certainly a valid tool for dealing with troublemakers, but it doesn't carry the same weight as being able to centrally found somebody. But I suppose that's part of the deliberate design here.
- inquist 5y ago♥
- deleted 5y ago[deleted]
- eru 5y agoVery neat: > 1.2.4. Messages are Authenticable, but not Opposable. > All Pest messages are authenticable -- a station will only process a message if it carries a valid signature from a peer (though in some cases, the message may not have been authored by that peer.) > However, they are also repudiatable (i.e. non-opposable) -- since all packet signatures are produced with symmetric keys, the recipient of a message cannot, at any point in time, prove to a third party that he was not in fact the author of that message.
- dathinab 5y ago> However, they are also repudiatable (i.e. non-opposable) -- since all packet signatures are produced with symmetric keys, the recipient of a message cannot, at any point in time, prove to a third party that he was not in fact the author of that message. So basically there is intentionally no way to prevent message forgery by the recipient. Why? Also tbh. how can I trust a person who in 2021 still hasn't understood that/why HTTPS is important for security even if you only provide read only content with making proper crypto/security decisions?
- wizzwizz4 5y ago“Message forgery by the recipient” is a bit strong. It's more like “lying by the recipient”, since the signature is only meaningful to the recipient. This stops stuff you say in chat from following you around, unless you choose to sign it with your regular private key.
- dathinab 5y ago“Message forgery by the recipient” is a bit strong. It's exactly what it allows: The recipient can forge a message they supposedly did receive. Try explaining "yes it's encrypted and prevents forgery, but not if it's forged by the recipient" to a judge or the media after there was a scandal ;=)
- wizzwizz4 5y ago
- rhn_mk1 5y agoI can't wait to try out some implementations.
- asciilifeform 5y agoAt the moment even the algorithm isn't finished.
- ur-whale 5y agoI'm not seeing much detail about the crypto (other than serpent and HMAC-512). Also: there is a claim of being DDOS-proof, but I haven't found an explanation as to how. Also: is there actual implementation or even a mock?
- edave64 5y agoI also don't see much DDOS proofing in this. Best I can find is that you can unpeer people, but since every message is rebroadcasted by everyone, that doesn't seem like much of a protection. Especially since, if the DDOSer has a lot of peers, it seems can be pretty imposible to know who the attacker even is, since there is no singed journal of hops or something.
- asciilifeform 5y ago"every message is rebroadcasted by everyone" is not factual per the spec.
- edave64 5y agoDo you mean some technicality like "only broadcast messages" and the deduplication list or something that can actually stop DDOS? There is also a bounce limit, but I would expect that (average number of peers) ^ 3 might be plenty amplification
- asciilifeform 5y agoOnly validly-signed (from one of the station's peers) messages move past the decoding stage ("prologue"), and of these only ones with timestamp +/-15min. of station's time; these finally searched for in dedupe queue; and at the end may be rebroadcast, if so marked, to the station's peers strictly. You can be DOSed, so to speak, by one of your peers, but not DDOSed by a third party -- a reasonable machine can reject signature-failing or replayed-stale packets from multiple NICs at line rate, so long as your WOT is compact (i.e. less than 100 entries). This of course remains to be experimentally tested. Currently there is only an algorithm!
- kwhitefoot 5y ago"Firefox does not trust this site because it uses a certificate that is not valid for www.loper-os.org. The certificate is only valid for the following names: *.nfshost.com, nfshost.com"
- edave64 5y agoThe concept of the "SelfChain" confuses me. It sounds like it would fall apart completely for anything except direct messages. If one person goes offline and all other people continue to talk, does that mean the next day my station considers all other speakers "forked"? And I have to unfork all of them? It's not like I can catch up since all messages are stale and discarded after 15 minutes. Do I allow a hearsay message to fork one of my peers? Can a rouge peer just come in, fork everyone, and leave?
- pabs3 5y agoReminds me a bit of Scuttlebut: https://scuttlebutt.nz/about/ https://scuttlebutt.nz/about/