Looks pretty good to me! This will be helpful in developing Project Decorum for sure.
I just wonder, why is for example HashSet<AppendedData> used instead of simply a Vec<AppendedData>? Isn’t the order of keys in a HashSet arbitrary? Or is that not the case here because it will never be resized?
Edit: One thing concerns me a bit, and that is that the cost to fill a Pub/PrivAppendableData without a white list with spam is zero. Public keys can be genereted en masse, so blacklisting won’t work against a determined attacker. In my original Project Decorum design, every reply costs a PUT and there is no kind of “reply list” that can be filled up. Spamming would thus be costly and would never result in complete denial of service.
This data list is required to be seen as “unordered” and any manual changes of ordering would probably be reset by the Vaults. Thats just a requirement to facilitate the union nature of accepting updates from multiple senders concurrently and treating them as valid updates and also allowing accumulation for GET requests.
Fair point. To prevent determined spamming white-list would be the only option currently.
In terms of cost for normal usage. PubAppendableData data holds AppendedData which itself holds DataIdentifier which needs a PUT by the sender to create. Again only in normal case. For someone trying to spam, they can just provide some random DataIdentifier to thereby cap the PubAppendableData itself without a whitelist.
the APPEND rpc also routes through the MaidManagers thereby incurring a charge for the sender to append info. Worth discussing for sure
I think I’m in favour of that. Also, since the network would be paid as AppendableData fills up, we could look for a way to somehow automatically/seemlessly extend AppendableData when it reaches it’s 100 KiB limit. Would be a bit annoying if for example a forum topic locks up just because it’s AppendableData is full.
Yes, I really like this one. The way I get it someone can add a “pointer” to something like his reply on a blog. So I write a blog, I open an AD for everyone to point to their reply. From the reply-er perspective it goes something like:
I read a nice blogpost, I make a PUT to write a reply and I point to my reply in the AD offered by the owner of the blog.
If I just want to reply with some weird smiley I don’t have to PUT as someone else probably already did this. So I only have to add the pointer in the AD. To prevent spam is has to cost some money, otherwise people start to fill up AD-fields with whatever and you need an extreme long whitelist. For a forum where you need to become a member probably not a problem, but for an open blog it is. So adding something to AD should cost a PUT or half a PUT maybe to keep spammers away.
Probably offtopic, but I’m trying to nudge a few people for pretty much this and not just for this type but for StructuredData too. I know @ustulation would very much like to have that in place too . Most of us agree with this being an annoying limitation and while it justified its annoying presence a while back, some of those requirements no longer exist cos say routing does a message split for transport itself regardless of the actual payload size from upper libs. Some points still do remain such as data concentration within a given group. There are answers, need some more bashing about and we should certainly be able to achieve it cos it is annoying and also creates loads of indirections forcing API’s to morph into linked lists to workaround these limitations.
Yip a next block on each SD/Appendable would be good, so then every SD etc. you create has a special link which always points to next block in chain. Sort of like a linked list, difference is that cannot be mutable AFAIK. So if an owner thinks that more than XX size is needed they create a next link item on the SD (link item is immutable, when it exists it cannot be amended or deleted), otherwise when it fills that is it.
That in itself should be an RFC though, there are many ways to do it.
From my understanding, it looks like the owner of the AppendableData is the only one who can actually delete entries from the AppendableData, while the closest someone can come to deleting an entry that they attached to an AppendableData that they don’t own is to delete the data that it points to and to leave a dangling pointer. Would it be helpful to add a mechanism for users to remove their own AppendedData entry from an AppendableData they don’t own, or is the current method of leaving dangling pointers (which could be cleaned periodically by the owner using a mechanism like the one for cleaning deleted_data) sufficient?
We have left this open to app developers. So for instance to say this app X requires you have immutable data that parses in a specific way (say email or chat or forum post). As this is immutable it cannot be deleted (in this case) so I may delete your email/comment etc. but cannot delete your data and neither can you. This saves people posting stuff then deleting/ editing a post to make it appear like an answer is wrong etc. (you see it happening here).
Other app devs may not mind and allow structured data be pointed to, allowing editing capabilities.
Other devs may not even care what the pointed to ting parses as or have them as pointers to videos/pictures etc. who knows?
tl;dr We have made this extremely open to app devs to specify a fixed format/editable or not etc. but only owners can remove the links in the appendable data.
It seems the obvious next type to add here will be push aware data items for more real time chats in band (out of band chat is Ok regardless)
I suspect much of these dynamic data types will evolve on a short period. That will be API breaking, but as @neo pointed out recently these perhaps could make use of the tag type more like a mask. Thereby setting the attributes of the SD type.
We were contorted the other day on whether the appendable types are specialisations of SD types or there is perhaps another base SD type and the other types inherit them etc. It may be the tag becomes a mask bit to state the attributes of a fundamental type? This is where we need folk to create apps and tell us
Do they have the functionality they want
How easy was it to get the functionality
Is there a cleaner way to provide greater functionality with a simpler API.
Yes does mean breaking changes up to version 1.0, but I feel if these changes are considered and tested then API 1.0 will be widely used.