This should be the same for any popular data. Whereby it can be cached along the route. It may mean there’s some delay in seeing updates, perhaps. But it should ensure the data remains available.
Registers are now stored at adults. They should be subject to the same (or similar) caching strategies as chunks (though this may affect new data availability on popular registers… perhaps we need lower TTL for register cache eg). It’s something we’ll need to consider more I think.
If such an API helps us be more flexible for applications atop Safe, then it’s probably a good move
The “select users” may well be possible when we get multisig setup (the key will be configuring thresholds for ownership, I think).
There may be space for flexibility here down the line. The flows around this will be fleshed out more as we get the DBC integration in.
Something else that may impact the above is the idea of using SafeIds (WebIds… but on safe). With one of these you could specify your inbox registers (or many of them) there, for users to find when they access your Id. I wonder what (if any) impact this could have on spam (if there are many inbox options in many sections).
I also wonder if inboxes registers might be derivable from a user’s PK eg. Such that registers dont exist until they are needed. Potentially giving a much wider name space (but searchable) for registers, as opposed to having to create each one and list it…
It looks like the purpose of public registers is that their data is simply always readable by everyone forever (like public files). That leaves private registers as the only way to completely prevent readability, and so it’d be nice if they were more flexible.
I know this (with public registers where everyone can read all entries) would probably be very secure, and I know that an additional layer of encryption like PGP could also be done. But it would still seem/feel better to me to have the amount of potential entities who can even try to crack your encrypted emails and analyze your inbox’s DAG be limited (by instead using private registers with permissions where only the owner can read entries) to only those few nodes that processed and saw your data, vs. the entire world being able to forever.
What I meant by “write-only” is that a non-owner cannot perform any read operations. But PublicPolicy::is_action_allowed always allows Action::Read regardless and does not check the permissions map in this case (and PublicPermissions::is_allowed always allows Action::Read), in contrast to PrivatePolicy (and PrivatePermissions). If it weren’t for that, it looks like PublicPolicy with permissions that do not include User::Anyone => Action::Read could achieve write-only.
Another reason I think private registers would be preferable is, IIUC, that enables a register to be destroyed, but public would require registers to be stored by the network for eternity. For applications like my email idea, the ability to destroy seems good because it enables an owner to remove this data from the network if they so desire for reasons of caution and/or to be a nice citizen by reducing the amount of data that nodes are responsible for.
To me, it seems more desirable for them to be able to allow access by non-owner users with the full flexibility that the policy permissions are capable of.
Why does PrivatePolicy::is_action_allowed, which can have permissions for non-owner users, not fallback to also checking for User::Anyone like PublicPolicy does? That prevents having a simple blanket permission for anyone, because, while User::Anyone can be included in the permissions map, only the requester: User is checked for and it looks like command-messages and query-messages cannot come from User::Anyone and so having that user in the permissions map is effectively pointless, for private registers. (I think messages cannot come from User::Anyone because it does not have a key-pair, and so such messages could not be signed as required for commands, and Client has a Keypair (as opposed to supporting User::Anyone) and signs queries as well as commands.)
But a register with permissions that only allow writes from specific users (i.e. User::Anyone => Action::Write is not in the permissions) would deny writes from any others. Isn’t such currently possible?
If, instead, the permissions were to deny only specific users and allow anyone else, then I’d see what you’re saying with being able to create new users to bypass such permissions, and that’s why I did not suggest that case.
That’s good to know and sounds helpful for reads as a DoS vector. A delay in seeing the current-value updates is a reasonable tradeoff.
But does that, or something else, help protect against a flood of writes as a DoS vector? Even with registers stored at adults, aren’t the smaller amount of elders still fairly involved in processing writes? Do nodes that are earlier in the routes to a section somehow throttle how much traffic they’ll forward to it and thus stop a flood coming from many directions?
Do you mean deriving from the recipient’s PK (as opposed to a sender’s) so that a random new stranger who has not been introduced would be able to only know this PK, and a register could be created with an address (an xor-name that the creator can choose) derived from the PK?
Maybe the deriving of an address would also involve the current time, in which case the recipient would not need to be informed of the address. The recipient’s app would just check all registers at all such addresses, for each time interval of some agreed-upon duration, and after retrieving new emails (entries) it would then abandon (ideally destroy) these registers. For further spreading-out, say for DoS resilience, there could be multiple registers per each time interval whose addresses’ derivation additionally involves an index from a range.
But who would create these derived registers? If senders were supposed to, that would be a race condition and the first to create it could set permissions that prevent others from being able to send (write) to it and/or prevent the recipient from accessing it. If the recipient is supposed to create, then their app would have to be online continuously doing this, and it would not be “until they are needed” like you mentioned, and other users could (intentionally or not) steal these registers by creating them before a recipient does and thus prevent it from working. I suspect that all other global sources of information that could be used for address deriving, that both senders and recipients can know without being introduced, would also face this problem.
With many registers for a single logical inbox, the email app would have to be managing this complexity, and I’d vaguely wondered about that possibility.
Hey! Are there plans to include any form of e-mail or message exchange in official Safenet release, as an integral part, Like example e-mail app in Fleming (or earlier) release? Or maybe just some messaging API ready to use/extend by 3rd party developers?
We’re also thinking about integrating traditional e-mail with Safenet. I think creating Xor address from e-mail address is possible, so we can have an identity based on someone’s email address. Perhaps for sending e-mails to/from Safenet some gate could be created… but then it’s centralized, although traditional e-mail is centralized anyway. Or maybe simply at application level, checking if an address has an ID under e-mail’s xor address and send by Safenet, or by traditional e-mail otherwise.
Ensure that Client-to-Client direct messages are free. It will charge, however, for Client-to-Client messages involving traversal through the Safe Network
Does it mean text/file messages sent by people, or just some internal protocol messaging? Is client-to-client messaging API implemented/planned ready to be used?
The client to client is direct communications through the network using the protocols. The exact method has not been revealed or not yet determined. This is like peer to peer on the current internet, no storage involved. So network packets are passed client to client and depends on APP to generate/receive the packets.
eMail (or safeMail or just mail) would have a sender and receiver IDs. IDs on Safe can be generated on or off line and used. The users account will store these IDs and available for APPs to use, so the mail APP would be using one of the IDs the user has (or newly generate one). IDs are public&private key pair.
This allows users to send mail from their “official” ID. Or send from another ID which potentially could be a “throwaway” ID
Mail would most likely be using a messaging system and the contents of the mail a data object on the Safe network encoded with the sender’s private key and decoded by the receiver using the sender’s public key. For even more security then another encryption using the receiver’s public key is done so that only the receiver can decode the data object. This double encryption also has the advantage that the receiver knows who sent it because only the sender’s public key works. And the sender knows only the receiver can decode it.
I have been thinking about the possibility of testing communication in Safenet for a long time, because it seems that it should be the basic functionality in the entire project, so I would like to find out more about the current stage of communication between users (email, communicator etc.)
In the roadmap (Fleming Feature) states, that the QP2P functionality has the “complete” status, while the “Apps and User Experience” chapter states that the Private Messaging functionality has the “concept” status.
Should it be understood that QP2P is an integral, ready-to-use solution at the network level, and Private Messaging still needs to be developed at the application level?
there.
. I just thought I should clarify since I’d referenced “follow” and “above”.