First I want to apologize if some of the topics are already discussed.
- CompletableFuture boilerplate
Currently all operations that call NativeBindings.* use CompletableFuture to store the result even for operations which are definitely non-blocking like
The result is that each time we need to call
future.get(); which is kind of tedious and verbose. It also may throw
InterruptedException which I am not sure if it is needed for (at least for) non-blocking operations.
One possible solution is to wrap the entire, lets call it Level 1 API in a wrapper API which hides the boilerplate and gives the Java developers synchronous API which is easier to use.
Other solution might be if the bindings are generated in a way that is synchronous, so no wrapper is needed.
- Estimating the cost of operations
At some point we will need a way to estimate the cost of a operation or series of operations. For example if a user queues several write operations that produce logical unit it is good idea if he is able to call some method in order to see it he has enough balance to execute all of the operations. Otherwise if the last operation fails the logical unit will be incomplete and all the "money" spend on the previous operations will be wasted.
Is there an idea how this problem will be approached?
- "Manual" mode for the Authenticator
Currently the app authentication process is interactive. But what about headless server programs, for example a daemon that acts like an indexing crawler. How it will get its authentication data? I imagine that it will have a command line parameter to generate the auth request as string and then the user will have to copy and paste it in the authenticatior and copy and paste the auth result in a config file.
Is that the idea?
- Auto-expandable mutable data (paginated Key-Value store)
Currently when new items are added to a mData it expands until it reaches the 1MB limit and then is starting to return error (ERR_DATA_TOO_LARGE).
From practical point of view it is quite tedious to check each time if that is the case and handle it appropriately. It will be very nice if there is a new mData type that automatically creates new internal mData (page) and also automatically handles the requests, i.e. the developer just feeds the mDataInfo of the first page and the API handles the rest. Currently I am creating this functionality in my java lib but I was wondering if it is good idea to be implemented in the lower level since it will be used by all client libs (c#, js, etc.)
- The sudden death problem
Currently if the user loses his login credentials, or worst, they get stolen that leads to sudden "safe network" death (for him). Losing login credential happens rather often and I think that many users will be frustrated if they are unable to recover their account.
I saw discussions about this problem in the forum, but did not saw any "final" decision. Is there an idea if there will be some more user friendly solution or we will stay with the current?
Btw, probably Level 2/3 (wrapper/app level) solution can be forged where accounts are created in pairs - one is “hot” for day to day usage, which shares everything with the second account which is “cold” and login credentials are kept offline (and used only on (more) secure device only when needed in case first account is lost or stolen. If the first account is compromised, all the owned objects can be transferred to newly created “hot” account (and first account’s Permissions are removed)
- Aging (and prunable) data
I know that a main principle of Safe network is that no data is really ever deleted but for some type of data this seems wasteful. For example I am working now on a chat app. Each user has separate mData for his part of the conversation and that mDatas are constantly updated. I don’t care about the previous versions of the mData, I just need the last one. The old versions are totally useless since the latest version contains the whole conversation.
Probably it will be good idea to have mData type that prunes older versions of the mData after some period or even the latest version if its age is above predefined limit.
- Pay or burn
This is controversial, I am sorry.
The idea that GET operations are free really bothers me. I have raised this question before in this forum. The more I think about the problem the more I am convinced that in order to prevent DDOS attacks we need to force the user to either pay "money" or burn CPU cycles in order to get the right to execute GET request.
If the user does not want to pay he will have to provide proof of work to the proxy server in order to get the right to execute given number of requests. The idea is user to be forced to burn at least the same amount of CPU cycles as the network uses to handle his request.
The other alternative is user to pay for executing GET requests with safecoin or other means.
Btw, burning can be alternative form of payment if some POW cryptocurrency is mined in the process.