Open miguelfreitas opened 10 years ago
Fantastic, I've been interested in this too. So far just studying how Twister works.
1) For the local user: so nodes would have the concept of users still, which would be a list of usernames to call startTorrentUser() on? And then the user could query the data for those names through the classic interface.
2) Followers: can they not be signed by your key client side?
3) If you're going to have a server doing POW, then it should only do one nickname at a time with a queue for nickname registrations. However I see this as an attack: I could easily fill up the queue with my nickname registrations dropping other people. Would be better (long-term) if a separate tool (maybe also another service communicating with twisterd) handles doing the POW.
4 & 5) sounds good
you mean you want to rewrite twister to full js? and how you want to get rid of private keys ?
The server could challenge the client for the private key for authentication before updating the followings.
Or the followings are simply not stored on the server but on the client and anyone could request any feed/torrent from any node. That way you could be connected to multiple servers. One of which is your outgoing server which you use to post/send messages. The other one(s) you would use to track your feeds/torrents. The second server would not have to know who you are. So your followings would be secret if you want.
@Tschaul good idea! (server challenge replaces password)
We could do the following:
The server publishes a nonce (random number used only once) which it updates say once a day. Clients could query the nonce without authentication. Then the valid password could be derived by the user simply as privkey(nonce) and checked for validity by the server. The advantage is that the server does not have to send an request to the client.
Thoughts about what needs to be done to create a privatekey-less twister server for a full JS client with encryption.