Hacker News Reader

Comment by Aardwolf | Hacker News Reader

What if I want to host an interactive server instead of a static document/file?

Why wouldn't the interaction be peer-to-peer as well? The point is to remove servers from the system, so there should not even be a concept of an "interactive server."

I mean for example an online game. To run it, I would need to have a computer over which I have control and which runs the game. That computer would be the server. If it goes down, the game will be down. How does that fit in this system?

EDIT: or web banking!

Downsides of peer-to-peer (speaking in general):

  * No golden reference for content.

  * Updates are slower / content may not be fresh

  * Peers may not be online at the same time that you are online.

"No golden reference for content"

Can you elaborate on this? I am not sure I understand what you mean.

"Peers may not be online at the same time that you are online."

That is already the case now with social networking, email, IM, etc. I do not really see this being a serious problem -- P2P networks are pretty resilient to people going offline as long as some threshold number of people remain connected.

"Updates are slower / content may not be fresh"

This is certainly a problem, but perhaps not insurmountable.

About lack of golden reference: Illustrative but extreme example is Bitcoin. There is no golden transaction history. What emerges through consensus from your peers is accepted as the transaction history. If there are network outages and silos get formed, then content can diverge.

About peers being offline: I am not talking about people being offline, but their systems going offline. Say I want to publish a photo to my friends. Their systems may not be available at the moment my system is online.

I think that in both cases, Usenet serves as an example (and an old one) of how the problem might be solved. At worst, what happens is that messages arrive in a different order than they were posted, hence the importance of "References" headers and quoting posts (the rest becomes a UI problem). Digital signing defeats forgery (if the network fractures, then your signed messages will only appear in one of the pieces of the network until the fracture is resolved), and encryption and mix-nets protect privacy.

So let's say you wanted to build a social networking system on top of Usenet. Here is one approach:

* Use attribute-based encryption to distribute keys to your friends; this allows you to control who can see the posts you make

* To post, you encrypt, sign, and encrypt again your message; then you send it through a mix-net to alt.anonymous.messages

* Your friends all download from alt.anonymous.messages, decrypting those messages they can decrypt. Your signature tells them who made the post, and ABE ensures that only those who have permission to see the post can decrypt it.

You can imagine extensions for commenting on posts, or creating groups, etc. You can also see that Usenet is not really relevant -- any P2P broadcast system could be used.

Your example is practical, and something I might even like to use. In theory, each user could run their own Usernet server and that could be called P2P. But if the default configuration is to use a shared server, it doesn't sound P2P to me.

I will read up more on Usenet though. I have used it but don't know its internals.

You'll be able to do that with JavaScript. (It'll be very disruptive.)

It will be the mother of all disruptions, dare I say ;)

Reply on news.ycombinator.com