> -----Original Message----- > From: p2p-hackers On Behalf Of Bill Broadley > Sent: December 6, 2016 6:52 AM > To: [email protected] > Subject: Re: [p2p-hackers] p2p vs piracy vs corp/gov dictates > > I believe what's needed to fix p2p and allow p2p to match more traditional > providers like dropbox, box.com, skype, gmail.com, etc. is a 2 tiered > approach.
My thoughts exactly, but for different reasons. I personally don't really care about p2p (file) sharing. What I'd like to get is a better control over the privacy of my online communications in general. Basically, my starting point was that I wanted a self-hosted analog of WhatsApp/Skype that can also talk to other instances of the same. Iterated on it a bit, abstracted this and that and here's what I have so far: 1. Clients register and communicate with their base server. There are no provisions for migrating from one server to another. At least not initially. 2. Every client has an inbound message queue on its server. 3. Clients may "pair" between themselves, establishing a relationship. Once paired, they will be able to post messages into each other's queue. More precisely, once paired, a client will instruct their server to start accepting messages into its queue from its new peer. 4. Pairing can be local, or it can be between the clients on two different servers. 5. Each client has a unique ID and a public/private key pair. Public key is registered with client's server during when it signs up. 6. So the pairing is basically an exchange and verification of public keys between the clients. Once paired, clients will have everything they need to communicate privately, so all further client traffic can be encrypted end-to-end. Manually verifying keys is obviously a lot of joy, but it can be automated for same-server clients IF they have rudimentary trust in their server. Verification may also be automated to a degree if a client "pins" other clients' manually verified keys to some sort of "key list" on its server. So the next local client may piggy-back on that and skip the manual verification step. It's a simple 2-tiered p2p private message delivery system. Do one thing, do it well and then extend by building on top of it if needed. For example, it can have: a. A way for clients on different servers to search for each other by some public attributes, e.g. an email address. b. A way for servers to post into client's queue, to allow for things like client's online status notifications. That is, if I suddenly drop offline, my server will let all my paired peers know about the fact. Thoughts? Alex _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
