Would it be a good idea to reserve other type_tags for future development?
Examples
POR (Proof of Resource) tokens are meant as a back up, kinda like a spare tire in a car. Do we have a POR type_tag reserved?
Safecoin divisibility is big priority, at least for me. It might help to reserve another type_tag as we develop a solution down the road.
Network Version Updates? Not sure how to word this one, but it involves this thread SAFE network upgrades where we discussed how to go about upgrading the Network.
I think SD (Structured Data) is going to be bigger and more useful than we expect.
Joking aside I always remember famous technologists getting up with their now infamous statements on what will be “more than enough”. Like IBM in the early days saying small number of computers will be all the world needs (8 if I remember correctly). Others stating 640KB of RAM is more than ever will be needed on a PC and so on through computing history.
Is 10,000 going to be enough? What if a new feature requires a multitude of tag_types because one reserved tag_type is created for each and every living person plus near future people plus spare to replace lost info. Yea I know that is a long shot and highly unlikely in an anonymous system, but we do have 64 bits and reserving 2^40 tags is a drop in the bucket, but covers a whole lot of possibilities
I would think you can always chain Tag types:
Record Super_Tagtype( constant int 9999, supertag 16 bytes )
Record Hyper_Tagtype( constant int 10000, hypertag 64 bytes )
That’s the way I would do it, if I am ever going to need more than one Tagtype for an App
Actually I knew this but was just trying to illustrate the fact that often we think relatively small numbers (10K vs 18000000000000000K) are often not enough when we examine the last few decades of computing.
We never know if maybe actual alt-coins (not tokens etc) will need to have system status
We never know if new features spring up etc etc.
We never know everything we don’t know yet
10,000 is quite a lot for these things, but using history we realise that these small number have a habit of being too small and there could easily be a thing that causes the 10K reserved tag_types to be too small.
Take IPv4 address range. When IPv4 was designed it was thought that there is no way in hell or heaven that 2^32 addresses would ever be exceeded. Now we are running/run out. Not a good example since this is the reserved tag_types, but I mention it because what we think is plenty (over the top) today is often not enough in a number of years.
Since there are ever so many 2^64 then having 2^40 reserved will be a drop in the bucket
1 x 10^12 Vs 1.8 x 10^19 which is 0.000006%[quote=“Lazarus_Long, post:6, topic:7296”]
if I am ever going to need more than one Tagtype for an App
[/quote]
We are of course not necessarily talking of APPs here so that may not work so well when its a network core feature and not an APP, like SAFEcoin is going to be.
You’re quite right, that such a number might be exhausted in a decade or so. OTOH noone can know in advance how much will be needed and we are now talking about what the core network needs. Once the need becomes clear, implementing one hypertag type and one hypertag library is no big thing.
Especially important is: we cannot know what will cause that need. It is practically certain that, if it happens at all, it will be something not foreseeable now. Trying to implement what can be foreseen is hard enough already … When the need becomes clear we can implement a solution fitting that problem.
The number of reserved type tags is not clearly defined:
10000 in the mentioned RFC
15000 in the code
but 15100 and 15101 are used for directories and are above both of these limits
Another problem is that the predefined type tags are scattered in the code:
LOGIN_PACKET_TYPE_TAG defined in safe_core/src/core/client/mod.rs
DNS_TAG defined in safe_core/src/dns/dns_operations/mod.rs
(UN)VERSIONED_DIRECTORY_LISTING_TAG defined in safe_core/src/nfs/mod.rs
Everything would be clearer if the type tags were defined in a centralized enum, something like:
/// Tag types for Structured Data
pub enum TypeTag {
/// Login Packet ...
LoginPacket,
/// Dns Entry ....
DnsEntry,
/// Versioned Directory Listing ...
VersionedDirectoryListing,
/// Unversioned Directory Listing ...
UnversionedDirectoryListing,
/// User defined type tags
UserTag(u64),
}
Methods converting to and from u64 would be necessary to handle the choosen limit and handle ascending compability by later versions of network with new SD type tags. Associated documentation would also be defined here. This way everything about type tags would be defined and documented in this centralized place:
current predefined tags
unalterable limit between reserved tags and user tags
Just to be sure things are clear for everybody: 2^64 type tags are available and we are talking about the fraction reserved for the core code. The other tags (with values above the limit) are for the apps code.
Maidsafe developers won’t be able to use each of these reserved tags individually but they could use a set of tags at once, for example a SD containing a script to be executed with a priority from 0 to 255 could be defined as ScriptCode(u8).
And I suggested earlier something like 2^40 reserved, still a drop in the bucket. I used that high a figure because I think about history and how much people have underestimated things before. EG IPv4 when conceived was “ever so large a address range” it could not be possibly used up.
But is not coherent with type tags used by safe network for directories, registered users (= account packets) and dns entries (= public ids) which are all outside this range. For example, 15000 is the type tag for directories, so using this sample might create a collision with a directory.
Unless I missed the information, the devhub is not clear about the range. There is this extract:
The type tag we are choosing is just a random number here, although you must know there is a range of reserved numbers for the type tags, any MutableData stored with any of this reserved type tags will have a special treatment by the network.
Maybe the real concrete range could be inserted here.
The first 10,000 numbers are reserved 