Proposal for an Accounts and Assets "Link" type about stellar-protocol

[jedmccaleb]

Can you just do this with Manage Data?

[MikeFair]

It's unclear from rereading my post that what I was suggesting was a new "type of account" dedicated to acting as the "link".

In Graph Databases you typically have "nodes" and "edges" as separate types.
Edges have the identifiers of the nodes they are linking (oftentimes a single, directed, edge having a "from" and a "to"); plus data about the link between the two.

You can probably twist managed data into doing anything you want but that doesn't make it a native concept, nor easily suited to the task. The hope/idea would be graph like searches of the "who controls what" type variety.

Currently the general assumption seems to be 1 person, 1 secret, 1 account; however in everything but the most basic of demonstration cases I can't see that being the case. Stellar's rules preclude ordinary reasonable people from being able to use a single account for everything they do with every third party they'd interact with.

Being able to insert an "Account Tree" into the data set could make this more manageable, a more interesting ledger to research, and possibly even easier to "reason" about automated rules and off-chain approvals/automation. (For instance, I have a need to identify the "authorized distributors" of an asset, where the set of authorized distributors can change over time. Being able to create a "set of accounts" that can be easily queried would solve that.)

If you're an issuer, then I could see you wanting at least two sets of account hierarchies you can "traverse"/"search";
(1) Holders of my asset(s)
(2) The accounts I use to manage my infrastructure (e.g. Channel Accounts)

The bottom line is that people rarely work alone in isolation, they work in small groups, they play roles, they create hierarchies to constrain controls and risks; they also create hierarchies to manage information and reflect governance structure.

I believe the most likely outcome based on Stellar's current rules is Issuers will predominantly end up making their own managed accounts for holders and keep control of the accounts instead of holders making trustlines for multiple assets.

This means I will end up with lots of account ids, each for a different "issuer"/"exchange".
I'd like to be able to somehow link all those accounts hierarchically in the ledger to show that my account is somehow "over" those accounts, or those accounts are "sub-accounts" to my main account.

Even a couple detail fields to give accounts a couple "names" would be useful.

---

To shift gears a bit; I've been having this idea about creating "accounts" that aren't identified by a Public/private keypair, but simply an arbitrary SHA256 hash of a string.

The hashed string would use the Public Key of a real account as the "root" of the string.
Creating the account requires the account payment and signature of the "Root" account.
The Signers of this derived account defer to the root account until explicitly changed.

Among other ideas, this allows an issuer to create an account, derived from the string:
[ISSUERACCOUNTID]:[ASSETCODE]/[HOLDERACCOUNTID]

The Sha256 of that string would be the account id; but the signing keys for the account would be defined by the "parent" account. It's also easy for me to compute my account id for that asset...

This way the issuer can pay the reserve, and treat the account like one of its own, but I can still easily see it in my chart of accounts. Transferring XLM or other asset into this account would be how I "pay" the Issuer (the issuer would then transfer the payment out of this account).

This also helps with the idea of making assets into genuine first class entities instead of the side effects of a trustline that they currently are.
The account number would be the Sha256 of the string: [ISSUERACCOUNTID]:[ASSETCODE]
Unless otherwise changed, the signers on this account would follow the root account (The issuer account).

[theaeolianmachine]

Hey @MikeFair — if you have any interest in pushing this forward, writing a CAP draft, or moving conversation to our mailing list (link in the main README) to get some feedback will push things along further.