Support 3bot

[robvanmieghem]

Will be added to the ThreefoldChain

spec see https://github.com/rivine/home/blob/master/specs/3bot_registration.md

[GlenDC]

Tx fee should be tx version independent, has been the rule so far.

[robvanmieghem]

@GlenDC this is a ticket with functional ideas as a starting point that needs to be worked out still.

[GlenDC]

Most logical would be that the 3bot registers a public key which serves as its ID, no? This way it can proof its identity by signing with the paired private key.

This way the format would be the fixed amount of bytes of a public key (32 bytes?).

I would leave out the alias. It is going to complicate things a lot as I assume an alias still has to be unique. It means we would have to guarantee that at registration point it needs to be unique (ignoring aliases that have expired due to the validity period). Ok not that complex, but still not useful. In the end if we use the pub. key as the id, it makes it easy as the id is also used as part of the id verification, without any other mapping required by anyone.

All this keeps the registration tx very small as well. Optionally you could also add a arbitrary data field that can be used for metadata such as descriptions.

What is the point of the validity period, given that the 3bot registers it while registering itself? Can you give motivational examples for this?

I would also suggest to add a signature field, this has 2 purposes:

• it proofs the registration is done by the owner of the public key;
• it allows the bot to redefine itself with the same type if tx (as we would allow it given the owner remains the same), which allows for example the extension of the validaty period (should we keep this feature) as well as the modification of metadata.

If we implement it like this in tfchain, I could do the development, testing and deployment to testnet in a couple of days or less.

[GlenDC]

I know @robvanmieghem hence why I am thinking out loud here as to help work it out. Hope it helps.

[robvanmieghem]

https://github.com/rivine/home/blob/master/specs/3bot_registration.md

[GlenDC]

Ok, given the mapping between id and dns names (and other info) has to happen amyway, i guess it is ok like this.

Why is the active bool? Isn’t this defined by the validity period?

The fees I get now as well, even though they are quite high. Not sure if we really want to go for this though.

[GlenDC]

(unregistration, there needs to be at least 1 left)

I suppose we can make the null case the way to delete the bot though. Would allow that case and prevent the need for a unique capability just to delete it.

[GlenDC]

If you remove the threedold founders wallets and special stuff around it (including fees) you would get a truly decentralised dns bot service (given the stake holders are decentralised).

It could still mean we run an official service, but it would allow others to offer this service as well on equal ground.

[GlenDC]

Why is the active bool?

I was thinking about this question a bit, and thought a possible motivation could be to be able to reserve dns name(s) for a bot (assuming dns name(s) have to be unique¹?). But even for that motivation it seems to not fill any missing feature, as that could be achieved using a validity period in the past (including a null value), assuming we need that validity period property² (which I guess we do, but still curious to some motivational examples for it).

---

¹ Regarding the validity period, do we free up a dns name for any bot to take at registration, or do we keep it marked as used (by that bot that had already registered it, even though it is now inactive)? If the latter we could perhaps still put a rule that if not renewed (the validity period) in x amount of time it is free again until a new registration Tx. If the question is no to this question as well as the one before that, than the only way to free up a DNS would be to explicitly delete the bot, which doesn't seem like a good idea, as it would grow the amount of zombie DNS names significantly over time.

² would it work as a regular dns service, where the validity period is maxed at a certain time range, as to ensure it cannot remain reserved for an inactive bot? Or what would be the proposed rules for this property?

[GlenDC]

Created the technical issues for this feature request as https://github.com/threefoldfoundation/tfchain/issues/189 and https://github.com/threefoldfoundation/tfchain/issues/190. Those issues are both a proposal as well as full of open questions that will need to be answered all if possible. Please help me with answering these open questions @robvanmieghem if you can, together or on your own.

[GlenDC]

A technical spec has been proposed and added as PR: https://github.com/threefoldfoundation/tfchain/pull/193. It documents all details in full details, as to ensure we're aligned on the details and consequences. I prefer to wait for the implementation until we're aligned on it.

The spec can also be read in human-readable format at https://github.com/threefoldfoundation/tfchain/blob/4b9bd1fb8e375791dab2da3686c10f1f5c489c98/specs/3bot_registration.md.

[GlenDC]

Latest update from a technical side can be found at https://github.com/threefoldfoundation/tfchain/issues/189#issuecomment-431292494.

3Bot is ready to be validated (and played with on devnet). This can be done, while the story card is ongoing, as it is feature-complete now, and will design-wise not change unless the verification process concludes this is required. Hence it is now a good time as any to start verifying, as it is pretty big as it is already.

[GlenDC]

On the tfchain '3bot-registration' branch you can get the tfchain version which is feature-complete in terms of the 3bot-registration. Should be sufficient to already implement any support required on the JS side.

Creating transactions is done using the transaction pool endpoints, this hasn't changed. So once you support the new Transaction versions, actually creating them should be trivial. Working on the documentation ASAP, because some information is still missing (e.g. how to sign transactions), but beyond that all is good.

• The 3Bot registration concept and its technical details, within the context of tfchain, is documented and available at https://github.com/threefoldfoundation/tfchain/blob/3bot-registration/doc/3bot.md;
• the (tfchain) binary encoding lib is also documented at https://github.com/threefoldfoundation/tfchain/blob/3bot-registration/doc/binary_encoding.md;
• and finally, the three different 3Bot transactions, to create and update records as well as transfer names between 3Bots, are documented at https://github.com/threefoldfoundation/tfchain/blob/3bot-registration/doc/transactions.md#3bot-transactions.

open 3Bot Registration feature tickets in JS:

• https://github.com/threefoldtech/jumpscale_lib/issues/149;
• binary_encoding primitives, new in tfchain for the 3bot_feature, is already finished and merged, see: https://github.com/threefoldtech/jumpscale_lib/issues/187;