Metadata for Accounts

Project Proposals
#1

Here is a discussion about metadata on accounts.

I guess NEM has a couple of ways it could go. I could put metadata on a namespace, or on an account, or possibly on both.

The most advanced metadata features on a blockchain are from NXT, so I’ll take a moment to look at them. If anybody else has seen something more advanced, please let me know.

##Account Info

Pasted image624×524 64 KB

This is kind of cool. You can make a name for your account and a description. Name can be anything you want. Mine is JL777 on NXT. That is of course not me, I just wanted to see if I could so I did. (this could be an attack method for scammers) Description can be anything you want. All this is on the chain. When you send a transaction to others, they can see your name and I think they can even see your description. You can put anything you want in that description.

##Alias
Everyone here is familiar for the most part.

Pasted image624×538 50 KB

Of the three options for aliases is URI (think it should say URL). This links a name to an internet address. Option two instead of URL, I can choose account, where now an account gets a name. Strange thing though, these aliases are unique, so somebody else has the alias JL777, not me. And lastly, we have the vague “Other” option, where I can enter “data” whatever that means. I think it just means text and like description in Account Info, I can write anything.

##Account Properties.
I really like this idea and have talked about it before. I am so excited because nobody anywhere is doing this and I think it is a huge untapped feature. Everyone else is trying to figure out how to make a perfect token of value, but here we have the first example of an account as value, which is interesting because accounts can do so many things tokens can’t or won’t ever be able to do.

Pasted image624×536 62.3 KB

Here we can make either our own or another person’s account a virtual property. Then we name and appraise the property. This means the person that owns that account is now the owner of that property. This is okay for central authorities I guess to assign ownership.

One way that I think NEM really shines here is that if an account now has been assigned a value in and of itself, that account can now also be transferable. In NEM an account that is viewed as a valuable asset can be passed from person to person much in the same way a token is except in NEM it is achieved through the multisig options.

##Way Forward?
So here we have there three big ways to assign names, descriptions, and values to an account. I would like to hope that NEM can have a unified and coherent system for doing this. Namesapaces are great at taking us a step closer to this. I’m hoping that in NEM, it can all be under one system so it is clear.

I suggest we do this once, and we do it right. Take the best of all of these and add them together.
So how would such a thing look. Should meta data get attached to an account or a namespace or maybe both?

Some of the things to be considered could be the following:
Name
Description
Data
URL
Phone Number
Email
Signature
Property
Value
Other

And anything else? Or are there any other platforms with unique approaches to metadata?

Maybe there could be a reputation in metadata or a rating from a third party. Maybe certification.

1 Like
NEM can already do what Factom does now
#2

I mean being able to assign all these metadata is all nice but without means for verification it’s hardly worth anything imho. Problem is methods for verification are always centralized.
It’d be cool to have some more dedicated fields for namespaces though so you don’t have to put everything into the description.

Things that could potentially be verified in a decentralized manner (I say potentially because I’m not giving it too much though right now):

  • url
  • phonenumber (stretch)
  • mail
#3

I think namespaces goes a long way to verifying information in that namespaces are unique and so therefor if you trust that namespace, then you can trust the information underneath it. So in many ways the namespace is the verification.

Like if I get a land title from the state of New York, I need to make sure that namespace that created that title was legit.

Or if somebody is claiming the account to be from Google but it wasn’t created under the Google namespace listed on the Google website, then it is suspect.

So basically any of the information is basically verified by verifying that namespace that created it was legit.

It would be nice to have officially verified namespaces too, like some how Google could go through an application to show that it was the real Google and read Google namespace, but I am not sure how that could be done yet. I guess it would take a centralized service to do that. If you wanted to do it decentralized, then just each person has to look on the website of that company to make sure they say that their namespace is the one you think it is.

#4

Just be clear. I have no relation to JL777

#5

The other day Paul Snow the founder of Factom replied to my comment explaining a little bit about what Factom is. https://forum.bitcoin.com/post13025.html#p13025

At which point I realized, that NEM right now can do the same thing as Factom. To do that all I have to do is make a new account and then send a message to it naming the document and describing it. Then I subsequently send a hash of document and maybe a note about changes if I wanted. Each time there is a major important revision to that document, I could send a new message that account that signifies that document.

A free and open-source program like Quick Hash could be used to make the hashes. https://sourceforge.net/projects/quickhash/

But how to make it perfect.

In an ideal world, we could just apply meta data to the account. Something like

Document Name: xxxxxxx
Author: xxxxxxx
Description: xxxxxx
Hash Algorythm: xxxxxx

And somebody would also build a document upload into NCC and hash it and then place the hash in a transaction to the account necessary.

In fact, Gimre had long ago already taken a step to doing this when he uploaded a simple hashing feature in NCC. That can be found under settings wheel -> account details -> sign a token using a hash. Once a person can do that they can paste up to one page of text and get a unique hash proving that text in that form existed at that time and then post that in a signature.

What would be better would be a more advanced signing a token feature. Something possibly with more utility for any kind of document, not just text, like Quick Hash.

#6

So then I after I considered how to make a perfect Factom on NEM, then I was thinking about Meta Data more and while before I thought we should give people set fields like in NXT, I thought it would be much better to let people make their own field categories. Like why should we artificially limit what kind of categories people might want to use meta data for?

Maybe somebody wants a VIN # field, or somebody else wants a home phone number field, or somebody else wants a ingredients field, or somebody wants a country field, or somebody else wants an OS field and so on. Really how can we know all the uses that one can imagine.

I once heard a builder on Ethereum in the earliest days before any code was really written say, “I don’t know what actually people want to use the blockchain for in the future, but I want to give them a platform to do that.”

I think allowing editable metadata fields on accounts with editable data to support those fields is a way we can do that.

1 Like
#7

here is a good use case. with proper metadata, each sensor could be represented by an account.

this is interesting because sensors are going to be an exponential growth technology in the future. so the companies that service sensors will be set for huge growth opportunities. this is a little hard to imagine because sensors are not that important in the world of today, but in the world of tomorrow, they will be ubiquitous.

https://hacked.com/filament-deploys-mesh-networks-smart-sensors-internet-things/

The numbers of sensors will far out number the amount of people and these sensors will need a safe and secure place for value transfers.

1 Like
#8

These are some of the service abbreviations that Emercoin is using. What I was thinking is that maybe NEM could have a preset list of service abbreviations, but then if somebody wanted to make a new one, the could for a big fee. Kind of like Namespaces. Like, lets so there is no category for SIM key, but I wanted to do a project where I was making digital SIMs for phones, so I could pay 50,000 XEM and make a new Service abbreviation “sim” and define it as being a digital SIM for cell phones with x specifications. A person could now use a private key as a SIM. Also, anybody could use that abbreviation, not just me for their project. If we allowed service abbreviations up 4 characters for abbreviations would allow 16,000,000+ possible options.

Like why should we just have measly 10 abbreviations when we could open it up for anyone in the world to build on the system.

1 Like
#9

Why a big fee? Why would that custom abbreviation be expensive for the network?

#10

I was thinking because it would have to be indexed. Maybe it wouldn’t be.

There is also the issued that while 16 million abbreviations seems like a lot. If every business was make dozens to deal with different aspects of their work, we could someday run out of space. Would maybe need to make it 5 digits then.

If it could be cheap, I would be okay with that. Some people might already have to buy a namespace to make a meta data, so that would be one barrier against spam I guess.

I hope people need a namespace, that way just like with mosaics so that we can know and trust who produced the mosaic, with meta data it would be nice to be able to trust that Company/Organization X is the one that stamped that meta data and are the one’s that are officially recognized so therefore the meta data is valid and reputable.

the important thing is that Company X wants to build on NEM and they can make their own customized meta data category and then have a data field to enter data on a account by account basis.

#11

I maintain that some of those use cases are better sutied for arbitrary transactions.

#12

We should just keep it less complicated and allow users to add meta names (aka variables) into the account and to be referenced by a namespace and let them fill it up with whatever they want as content into the meta name field, i.e., instead of fixing a url, name, phone, hash, email, etc. as the meta names, let them create their own.

Mark the meta name field as permanent (immutable)/temporary (mutable), visible/encrypted.

Use this as a precursor to be used by smart contracts to write or read from it by way of using a key to open and read it if it is encrypted.

In the account have fields to enter the public keys of those who can read it and/or write on it.

Essentially, it has turned itself into a database set in the block chain to be used by smart contracts or anyone as a reference. It is generic and it has all the goodness of a highly flexible definition of an account meta data instead of dead setting it like the above.

With this flexibility, you can do all of the above and perhaps we can do more by defining the account’s use, e.g., adding maths operators in there as a formula to generate an output.

#13

Those are all very good suggestions.

Other things to consider are also letting 2nd parties contribute to other accounts meta data.

Lots of ways to do this of course, but I like the system where you approve people to be able to add meta data to your account. It would be nice if you could put a small contract on the chain that says, x account can tag my account with meta data. There could be more options like “only once/unlimited” or “with/with out my signature to approve” and so on.

This is not all too different than multisig, in that in multisig there is basically a contract on the chain that says, “now account x can send account y’s money”. This would basically just be “now account x can tag account y’s meta data”.

This is especially neat for “official” organizations that have reserved a name space. Then they can officially award upon other accounts status and certificates.

Also good for external smart contracts too I guess in that you could say in the contract, “only accounts with x tag can do y” when a code is being executed.

Think of QM’s XEM Pay/Sign on the faucet. What if somebody was a really good Nemster and earned a lot of loyalty points. An official NEM body could award that account a tag. Then QM’s script could be like award normal accounts 100 XEM, but accounts with a NEM loyalty tag could get 200 XEM each time they come to the faucet. Such tags start to make smart contracts a little more smart.

#14

Extending from that, a namespace can be use to attached accounts, like mosaic. In mosaic’s case it was mynamespace:mymosaic.

We could also do mynamespace:myaccount.

Further, if we could make mynamespace*myaccount balance only visible to the namespace owner and the assignee of the account, we would have such a powerful account system.

Metaname and metadata can be put into that account described as above and the owner/assignee of it can also use it to transact like any other account, or if no meta data is in there, then the account can still be used like a normal account to transact.

With that, we are done.

#15

I’ve always assumed that a namespace would be required to create new variables/tags and to actually apply them to an account. Otherwise if anybody can just say anything then it means nothing. Namespaces gives certain people/organizations authority so that other people can recognize or dismiss that info.

#16

what 's new about metadata for account, will it be a function of nem