Author Topic: Simple KeyID relationships  (Read 2494 times)

0 Members and 1 Guest are viewing this topic.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I.e. for a marriage on the blockchain? .. In don't get how the 'edge' between both is verified by both? Isn't it?

Offline toast

  • Moderator
  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
not getting it .. is it like a signed message on the chain?

It's like public data but it is "about" an edge between accounts. You can set only one direction. If you had an off-chain service that kept the history, you could use it for public message or a public "wall".
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
not getting it .. is it like a signed message on the chain?

Offline toast

  • Moderator
  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
I will add the ability for a KeyID to write to an "out" edge to another KeyID and set a json object.
One property on this object will be an object of "first-class" parameters which will have on-chain validation (which can be arbitrarily complex).

The idea is for us to be able to quickly prototype things like reputation systems and identity verification which can work without on-chain validation at all (I trust these 3 validators who publish good edge info, and can filter everything else). Validation could have access to public data and other edge data.

Edge from nikolai to vikram:

Code: [Select]
{
      "_chain": {
          "same_owner": false
     }
      "reputation_experiment_1":  "100"
     "real_name": "Vikram Rajkumar aka the Legend"
}

"same_owner" could be used to prove account belongs to one entity and would make a reverse index ("vikram", "nikolai", "same_owner") available.

If you had your own filtering algorithm for "reputation_experiment_1" then you could reliably make use of "real_name".

I think this that since we do not have a scripting environment, we need a straightforward way for people to experiment and propose validation logic updates.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.