Transactions - a chained type to replace CRDT Registers

[happybeing]

David, I probably won’t dive deeper at this point so just a couple of comments.

@dirvine

@happybeing

This will be fine for many applications, but something that is frequently updated will die pretty quickly if say, a social media app has to read the entire chain every time it is installed on a new device.

With registers this would be the same, so a register might hold a few hundred entries, but then it needs to split. With a CRDT tree you cannot split it so it grows forever, that would not work for us as it could grow more than 32 Gb of whatever nodes should hold.

This isn’t really the answer to my point - you’re saying in effect that Registers also turned out not to be scalable for this kind of use and that Transactions doesn’t solve that issue for many anticipated use cases. Social media being a big one, but anything that can grow over time that is around for a long time or has many ‘authors’ is going to be difficult or perhaps unachievable.

I realise this is in some ways much better than Registers, having found them problematic for months myself, but it appears to leave a key use case for them unsupported. Decorum for example. Anything where history is important over long periods risks becoming impractical to maintain in a history. So again we can end up with either centralised solutions or a decentralised web that forgets data by fragmenting in some way (even if the data itself remains stored on nodes, indefinitely). That’s my concern anyway.

Transactions, the name

Unrelated, I’d like to suggest a change in name for this type because Transactions are an application level concept. The name implies certain use cases that will get in the way of discovery and understanding for developers who can use this to record a sequential tree of anything.

I suggest a name that fits the underlying properties but isn’t already over loaded with meaning (or with misleading meaning anyway). Naming is hard!

At first I thought ‘Step’, rather than Link or ChainLink which are already used heavily but might still be worth considering. Maybe there’s a better term.

For my API I came up with History and would be content to let you adopt that for an API which creates a history for given data-types based on Transactions. The point is that you can have a history of anything so I chose Trove (collection of valuable stuff) for the underlying unit and so have:

• Trove a trivial trait you implement on anything you wish to create and manage a history for.

• TroveHistory<T> as a templated type so you can create and find entries using a templated API for your type.

• FileTree, a ready to use struct for storing a tree of files or a website, for which TroveHistory<FileTree> provides the API for managing its history, or similarly for any developer defined type.

Details are in docs.rs as of yesterday (here). Not usable by third parties yet but working in awe. It uses Registers for but will be easy to refactor for Transactions when they appear, or if you wish to include a History style API directly in the autonomi crate and steal the terminology I’ll be fine with that. If so, I would though like you to keep the Trove trait as so that the TroveHistory<T> can specify the type using the first element in the chain.