@Jaguar and Theis. Some thoughts from a friend.
-----------
There are things that I dont like about NXT or that I think could be done differently.
1. Storing whole blockchain in memory.
imo, app should be split into 3 parts:
1. server, storing blockchain and all related info in DB - this one would be used for all the SERIOUS stuff (so exchages, faucets, and any other apps like that would run this)
2. lightweight IN-BROWSER client - I think CfB has similar idea - that one, would have ZERO knowledge itself it, but I think itd be possible to do whole singing in-browser.
3. normal client - for users, that want to participate in the network, but dont want to deal with DB setup. This one would keep blockchain in memory, BUT it would rely on snapshots
a. snapshot would be created every X days (I was thinking about X=10)
b. they would contain information about state (of accounts), but would drop all the history
c. snapshots (for new clients) could be propagated in torrent-like fashion.
1.1 Agree, storage must be transactional secure
1.2 lightweight browser, maybe I do not get the point, but this is already available...IMHO GUI not very nice or attractive and not easy to unerstand
@UF could you ask to elaborate on this a little bit more
1.3 In principle I would agree, snapshots which get propagate are open for attacks and easy targets to fake snapshots
2. TPS rate. Ive seen somewhere info, that Nxt could handle 100_000 TPS. I have some doubts about it. (current hardcoded limit for tx in block is 255, that would imply ~400 BLOCKS per sec).
I think software, should be thought upfront to handle large amount of transactions per second. (so for sure, somewhere in future there should be switch to binary protocol, also it might be beneficial to use UDP to propagate information). what do you think about GHOST?
Also I got interesting idea, but Im not sure how it would work in practice...
3. Lack of Wallet. People simply got used to this. I dont think generating Secret Key by doing SHA on a string (like Nxt is doing currently) is a good idea.
4. Curve. Youve already written, youd like to switch to Ed, so I guess you think the same.
A. Server as a servlet - I think this is good choice for initial implementation (before adding binary protocol, also servlet, would still be needed if one would like to have IN-BROWSER client). But Id change one simple (and quite obvious) thing: instead of embedding type of query in json, It should be in URL itself.
-----------
A. Agree, maybe a kind of REST Api