“Pest” vs. 0xFE
loper-os.org
loper-os.org
"vs." being an abbreviation for versus carries an entirely different meaning than the intended version.
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.
Vpatches are backwards-compatible with ordinary gnupatch. (can simply execute "patch -p0 < nameofpatch" for the sequence.) "V" has nothing directly to do with Bitcoin.
> 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
> 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.
> 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.
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?
This stops stuff you say in chat from following you around, unless you choose to sign it with your regular private key.
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 ;=)
This digital signature proves the message was written by a party to the communication, but it doesn't prove which one.
Encryption keys can be used to make digital signatures. Anyone with the key for this communication could've made that signature; not just the sender, but the receiver as well.
(I'm sure you can think of more.)
I would want a system where I cannot repudiate messages that I sent, but I must repudiate (i.e. cannot claim authorship of) messages that I did not send.
As far as I understand, isn't that how asymmetric encryption typically works? What's the advantage of symmetric encryption in this case?
This flame is doubly funny given how the article specifically concerns algorithms for possible decentralized cryptonets.
HTTPSism is deliberately broken on my WWW, to annoy unthinking servants of the PKI Reich.
For the thick: at the start, there is a PGP-signed copy of the text offered. And yes I in fact live and die by my PGP identity. And not Verisign et al's NSA-controlled PKI horror, no.
Which shows you don't understand the problem.
HTTPS on content only sides is primary about preventing people with tampering with the website in ways which potentially can hurt you from just opening them. The increased trust-ability of the content is important too, but only secondary.
A PGP signed copy helps me to verify the content after I already fully loaded it with a lot of additional overhead.
It doesn't prevent JS injected into your side from being executed, does it prevent a injected http redirect to a fingerprinting site or similar (which e.g. could use non JS fingerprinting or potential non JS based RCE attack vectors, which luckily I haven't heard of in browsers in recent years but are not impossible at all.).
As long a browsers don't check the signature before loading/parsing any content it isn't secure.
EDIT: In general in 2021 using HTTS "doesn't cost you anything" (in the sense of nearly anyone can afford it), neither does it prevent you from still doing what you currently do (standing by PGP(oversimplified)) and being against the by now pretty much not-undoable not-decentralized HTTS infrastructure. But realism is a important part of security.
"people" here specifically excluding Verisign & its successor racketeers, the NSA (plus bananistani national equivalents thereof).
> in ways which potentially can hurt you from just opening them
Running shitware is optional.
> It doesn't prevent JS injected into your side from being executed
The only solution to malicious JS is... to switch off JS. Asking people you don't know to pay the cert tax does not somehow guarantee that their JS is not malicious.
> ... check the signature before loading/parsing any content it isn't secure.
"Secure content" is what you obtained from someone you actually trust and verified with a pubkey you received out of band (ideally -- meatspace). All other content may as well have been authored by evil martians, despite any pretense to the contrary.
> by now pretty much not-undoable not-decentralized HTTS infrastructure
What part of "Where I still have the freedom not to use the Reich's master-keyed pseudocryptographic garbage - I will not use it" is hard to understand?
IMHO it is quite strange that the "HTTPS-everywhere" nonsense isn't immediately understood by everyone for what it is -- simply Google's latest effort to stymie ad-blocking (with the applause of NSA, whose mission today consists largely of efforts to retard the development of actual - i.e. not masterkeyed and not escrowed - crypto.)
Do I allow a hearsay message to fork one of my peers? Can a rouge peer just come in, fork everyone, and leave?
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?
There is also a bounce limit, but I would expect that (average number of peers) ^ 3 might be plenty amplification
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!
And the trick is that you can't just be DOSed by a peer, you can be DDOSed by the peers of your peers of your peers, as I see it.
The most that can be done to infer authenticity of indirect messages is to see whether such a message rejects the authorship of a known previous message having the same handle -- via the SelfChain. In virtually any case of handle collision, this will occur.
Re: floods -- a station only processes messages from a peer. So in fact in all cases the proximate cause of a flood is identifiable, and you can "UNPEER" and "GAG" him.
Flooding by a peer is annoying, but is not what people normally think of as "DDOS" (normally the term implies a flood of rubbish received directly from unauthenticated third parties.)
How liberally to peer -- is a matter for an individual station operator. Peering with every passing acquaintance has obvious down-sides.