Spentbook

They have their own way to manage tasks. You don’t need a MaidSafe agreed view that covers everything. You are given an area of responsibility and work informally with whomever you need to, to establish the details and parameters. You get on with it and communicate with those who need to understand how your work is proceeding.

All this can work efficiently in a small team. In large teams you can’t do this, or where there needs to be tight budget and timescale management. Here neither apply, so a small team can work informally and much of the task management can be done by the individuals or pairs working in a particular area, maybe never written down.

I’d be very surprised if there was one person with a list of everyone’s tasks (because to be useful each task would have to be defined in detail, not just a handful of words). But even if there was, publishing it would create unnecessary work and slow the developers down as I’ve explained.

Hope that makes sense.

5 Likes

My understanding is that at this stage of development the list of features or rather requirements is fairly short

  • Clients need to be able to connect reliably to the network
  • Data needs to be stored with redundancy and without loss
  • Data needs to be reliably retrievable
  • The network needs to be able to scale by smooth section splits
  • The network needs to be Byzantine fault-tolerant
  • The network needs to be ‘usable’ in terms of speed of data uploads/downlaods, CPU and memory consumption (can be optimised later)
  • The network needs to be stable and predictable
  • There needs to be a usable front end (CLI in the first instance)
  • There needs to be a workable economic model and means of transacting

With the exception of the last two points the rest are all closely connected mainly revolving around a small number of building blocks, particularly the sending of messages between nodes and AE. So progress in achieving one milestone (eg clients connecting reliable) will be immediately transferable to other areas because of this building block approach.

With each building block being worked on by an individual or two, progress, when it happens, can be rapid, but because progress is not linear or particularly predictable it’s not amenable to a tickbox approach.

11 Likes

Makes sense, thank you for the detailed response.

3 Likes

John, those are requirements/specification rather than tasks. The key difference here is that some requirements might be ticked off as you go, but many will only be met when the network is finished. Whereas tasks can ask be ticked off as they are completed so give a better sense of both progress and remaining work to completion, although neither are very reliable.

2 Likes

I’m not sure how communicable the tasks would be, in that most of them will be bug fixes. Therein lies the problem.

2 Likes

@Vort

I like the sound of “spendbook” better but note the finality to a “t”. Think of it in the abstract as a big “data base” of transactions and you might like the spen-db-ook too.

4 Likes

Enough of this pandering to the D people!!!

Let them learn their place and realise it can only ever be SpenTbook signifying past tense. Done and dusted. These transactions are in the pasT.

3 Likes

Is that really true though? Not so sure here as I’ve skimmed the reading while multitasking. The clients write to the SpenDBook first, then need it validated before they can spend it. So spenD is a better descriptor, no? Only after validation is it done and dusted, right? SpenDBook it is.

3 Likes

I hate it when bastards bring logic, reason and facts to an argument.

6 Likes

Yes it is true. It’s a list of spent transactions, not a list of dbcs that clients are able to spend.

Transactions that are written to the spentbook are now spent. The stamp of approval that comes after that from the mint only adds authority, but does not change it from being spent. Once the client writes to the spentbook there is no second chance to spend it differently, so it’s spent.

The literature for dbcs uses spendbook, I personally feel it’s a spentbook, and the difference is important for building an intuitive understanding of what this thing is.

Spend is a verb. It’s implying that the book lists something that’s ‘in motion’ or ‘happening’. This isn’t the case here.

Spent is an adjective. It’s describing the state of the data. It’s in the past, spent, not able to be changed, which is an accurate description.

To use a bitcoin analogy, spendbook would be utxo (ready to spend, able to spend etc), which the dbc record is not doing. The spentbook is any transaction that’s completed, ie the bitcoin blockchain not including utxo. It’s an important distinction since it affects how we can use the data, eg can it be used for an audit or not? Can it be used for linking history or not?

11 Likes

Maybe the “spendbook”/“spentbook” term could be replaced with something more descriptive altogether. The writing to the book by the client definitely infers a kind of journal or ledger but then the authorization to disseminate funds goes a little beyond a simple journal/ledger, it entails some kind of disbursement mechanism, if that is included in the spendbook’s realm of responsibility.

1 Like

Recently Approved Transactions or the RAT?

It’s just a record of a transaction, nothing more complex than that. The authority to disseminate funds lies purely with the mint.

Exactly! It’s an ex-DBC, gone to meet its maker, etc.

4 Likes

A DBC with a Norwegian Blue watermark :slight_smile:

3 Likes

Glued on its perch the poor wee thing.

1 Like

In this case, I believe “spenD” denotes the atemporal infinitive, not the present tense, or the past tense, like “spenT” would. So I admit to being partial to “spenDbook”.

But seriously, the important thing is that it’s consistent. It could be “spenXbook”, as long as it’s the same everywhere.

The above statements are not true, strictly speaking, but the explanation is beyond the scope of this post.

5 Likes

I’ve never heard of atemporal infinitives. You are the fount of all linguistics knowledge @Sascha. Respect. But don’t you think the important thing (apart from consistency, which I agree with) is that it’s in the past, spent, immutable, deceased … It’s not really a book either - but let’s not go there!

5 Likes

Well. We are getting pretty deep into linguistic theory here. Right now I can’t think of a temporal infinitive in any language. However, infinitives can have aspect, e.g. in Russian. The perfective aspect infinitive (most naturally) denotes something that has finished happening in the past, whereas the imperfective aspect infinitive denotes something that’s ongoing, be it in the past or in the present. But that doesn’t mean the infinitive is “past” or has tense at all. The point is that aspect (or aspectuality) and tense are different animals.

EDIT: My understanding is that Bulgarian has a very rich morphology of both tense and aspect. Tense is less important in Russian. Ping @Dimitar.

6 Likes

Your chickens must be very well versed.

6 Likes

I do understand some “chicken”, and I can even speak a tiny bit, despite my vocal cords being what they are. But chickens are practical beings who don’t care much for theory.

7 Likes