Move some of the authentication logic to HTML client, allow node to be accessed publicly

[dionyziz]

It's currently hard to set up a twister node. I expect it to be hard to do for even power users for a while, and for regular users probably for ever.

It may make sense to allow multiple users per node. For example, I could set up a twister node on my server and allow it to listen publicly on, say, "twister.dionyziz.com".

Then anybody who wants to use my node can just go ahead and use it. Of course, I would be still doing the proof-of-work and peer-to-peer data distribution at the node level.

However, it may make sense to add some sort of authentication logic to the client. For example, we could use a password to login, which would be used locally (via JS) to decrypt (think PBKDF2 + AES) my private key, which could also be stored locally (HTML5 LocalStorage). Then the node could delegate to the JS interface to do the encryption part.

There are serious and probably hard to overcome security issues with such an idea. What is our threat model, and how much do we trust the node? If they can send arbitrary JS code down to the client, they can potentially do whatever they want. Also, this proposal centralizes parts of the network, and therefore loses some of its strengths. Under this criticism, it seems that these are insurmountable and it doesn't make sense to implement them.

However, I think it makes sense to discuss this for the sake of argument to improve usability and to spread the platform.

An alternative model would be to require users to trust their node, but still use a password for authentication per-user. Then the private keys could be stored on either the node or on the client. In this sense, this is similar to Twitter's client/server model but in a per-node basis. We still need passwords because multiple users can use the platform and we don't want one to login as the other, regardless of how much they trust the node.

What are your thoughts on this?

Thank you for your time.

[miguelfreitas]

@dionyziz yes, this make a lot of sense! I agree with that plan, but imho the threat model require us to do the javascript client authenticated by browser extensions mechanism (chrome at least). The server must not be allowed to send arbitrary JS code to the client, we would only be running trusted JS. Then the server (a kind of twister network gateway) could be provided by anyone.

I think the only use for client-server password authentication would be to setup the list who you follow. Some ideas are discussed here: miguelfreitas/twister-core#4