[Outline. Will be making a mathematical post later ...]

The theme is one on which papers occasionally come out and have been coming out for years and I think some thoughts about it in the context of tokens are due.

Fast, large databases, those with with very large variety in how information is entered, and great flow in and out, are very hot. At least B2B at the moment.

There are a lot of recent, interesting frameworks that have not yet built into a product however.

Each of those, so far as I can see, can also be generalized.

[I really wish blogs could render LaTeX and TikZ ... but whatever ...]

A short summary of one approach with, I think, a future.

(1) Cells are smart databases. Which arbitrarily many different services can read and write to concurrently. It's one of the more modern approaches (originated in mit) to scalable concurrency of services with high data flow, high data heterogeneity. To build high flexibility. Seems interesting for easily (and elegantly) building a high activity marketplace.

Services have no memory. (For simplicity but also for security.) A cell has various links to some services and not others. These links can change. A cell can receive a message to make the nonoriented link (Cell---Service) oriented (Cell-->Service). The linked service then sees an initial input and starts working. When done processing, it sends output to the cell, possibly changing --> back to ---. All the cells linked to a service are its neighbors. No services most often are not linked directly. Linked through such mailboxes. It's a net.

So no time management needed. All services work asynchronously. Concurrently. They don't wait turns. And no managing of the waiting of turns. Which eliminates the biggest constraint to rapid and easy development and later user experience flexibility.

Many services can write and read to the same database. Which uses one of possibly several rules for merging inputs [SUS08,RAD09]. Or stores many as they come in. Where in a tree then varying with which situation that input is part of [HEW76]. Which incidentally allows symbolic evaluation.

Any working service can look into any of its neighboring cells if it needs further information.

If it gets y and performs f(x,y), it will search, looking at neighboring cells to which it has any links, for the missing x, if it finds it copy it, and do f(x,y), then drop the result in some cell based on f(x,y), or x, or y, or some rule, else wait, searching again periodically, meanwhile doing other work.

Many services can interact in many ways at once, as needed, over many sequences of services and cells.

It's easy for service providing parties to join into this kind of system or leave the system while it works, very little coding required. Which reduces barrier to usage, and the system grows in capabilities, therefore possibly utility, faster than the number of services in it increases, as that number grows.

(2) Suppose, basically, you are building a variation on the theme of a marketplace, and will reward buyers and sellers with tokens for transactions. To encourage them to have more transactions. Tokens have utility in that they allocate and control services or redeemed for other goods. Large enough prospective user count? I'm thinking ...

i) marketplace with token rewards (default),

ii) marketplace with token rewards and infrastructure for web services type rewards,

iii) more or less complex rewards ... ?

Allowing third parties to easily offer web services and tokens are the user interface. But they must be able to integrate conveniently.

Beginning the building of web services framework that allows, for example, third parties to offer web services for tokens should put a harder, utility based floor on the value of utility tokens which are the rewards. And presents the best trade off regarding architecture that is needed that is also interesting and has valuation prospectives.

More complex rewards would have to be much more complex to be interesting. Simple rewards would be boring, unless the system reaches so many users that just about any product appears on the marketplace and can be obtained with rewards tokens. But directly competing with something like amazon, without the advantage of some difference would be too risky.

(3) I like it because I think it will be easy to pitch, because it has a broad use case and market applicability, easy to add use cases that hedge, easy to position, and it's mathematically interesting to me. (Multicategories as a model, for example.)