Proposal for an Accounts and Assets "Link" type

[MikeFair]

Hi all,

I'd really like to formally link accounts and assets, especially into hierarchies. Think of something like a Chart of Accounts, Parts List / Bill of Materials, Purchase Order, Paper Portfolio, or Index Fund.

This would be a new object type that links two addresses or assets in the system via a from/to. The two link fields could done as "trust_lines" (a from line and a to line). Setting the AssetCode to "" or null would represent an account link, otherwise an asset.

This object has "type" and "name" strings and Managed Data fields for properties of the "relationship". Using this "Link" object is completely user defined and has no formalized in-system meaning.

The operations I see are of the standard CRUD fare; but a convenience API to also return the linked Accounts (if they are Accounts) would save from a couple trips back to the servers.

Thanks, Mike

[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:

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.

[Taylorman3]

Hi all,

I'd really like to formally link accounts and assets, especially into hierarchies. Think of something like a Chart of Accounts, Parts List / Bill of Materials, Purchase Order, Paper Portfolio, or Index Fund.

This would be a new object type that links two addresses or assets in the system via a from/to. The two link fields could done as "trust_lines" (a from line and a to line). Setting the AssetCode to "" or null would represent an account link, otherwise an asset.

This object has "type" and "name" strings and Managed Data fields for properties of the "relationship". Using this "Link" object is completely user defined and has no formalized in-system meaning.

The operations I see are of the standard CRUD fare; but a convenience API to also return the linked Accounts (if they are Accounts) would save from a couple trips back to the servers.

Thanks, Mike

__

[MikeFair]

Hi, I have not been following Stellar advancements for a few years now.

From a financial services standpoint I still believe this would be a useful addition. But as I'll explain below, ultimately I was trying to turn a SQL database into a linked node graph database. If this was done, a CYPHER or similar graph based query endpoint would be the next request.

It seems I never answered Jed's question about using managed data. Short answer,, not really.. The problem is filtering out "child assets" from other managed data. Ultimately, aren't "Assets" just a separate bucket of managed data?

It would be a separate proposal, but genericizing the idea of "Managed Data Type" where "Assets" are simply one class of managed data bucket seems very useful to me. The "type" field would help greatly in letting application programmers know how to use that bucket of fields; similar to how file extensions are used for files today.

There is always the technique of the managed data pointing to some off-chain storage, like IPFS. So sure, anything can be done that way too. This doesn't change the "how do I query the child assets?" issue.

.....

In rereading my original proposal, thinking about other things I'd proposed, and thoughts in general, I realized that what I was really pushing for, collectively, to make a file systems comparison, wasn't like extending an existing FAT 8.3 filesystem into FAT32, but more like turning it into ext3 or ntfs.

That the ultimate aim (without realizing it at the time) was a peer to peer, distributed, consensus updated, graph database like neo4j, with the data stored off-chain in something like ipfs, where different administrative domains (accounts) could act as database roots.

It's only superficially the same kind of thing. I was wanting a data management system, not an asset balance system.

I was thinking about the datasets and systems the investment management companies I worked for used and developed and what data should be publicly shared and what needed to be kept internal, and was seeing accounts as nodes, repositories of KVPs, as a means to that end.

I was looking to encapsulate automation and manufacturing processes to move beyond the financially related domains. For example, a specific car, and the hierarchy of sub-assemblies required all the way down to the individual fasteners. Then we could have both a generic car template for making the car, as well as cloning that template to fill it out with specific serial numbers to make a specific VIN. Mechanic shop repairs and after market modifications could be tracked on a specific car.

I realized I wanted Stellar to "be something else". I saw Stellar's consensus system as a means for generic data structure transformation, not the specific application it seems intended as.

I still believe a consensus based, p2p, queryable graph database is a fantastic idea. I can also appreciate it's a superset of the present intended application.

On Sat, Oct 12, 2024, 3:21 AM Melvin Andrew Taylor @.***> wrote:

Hi all,

I'd really like to formally link accounts and assets, especially into hierarchies. Think of something like a Chart of Accounts, Parts List / Bill of Materials, Purchase Order, Paper Portfolio, or Index Fund.

This would be a new object type that links two addresses or assets in the system via a from/to. The two link fields could done as "trust_lines" (a from line and a to line). Setting the AssetCode to "" or null would represent an account link, otherwise an asset.

This object has "type" and "name" strings and Managed Data fields for properties of the "relationship". Using this "Link" object is completely user defined and has no formalized in-system meaning.

The operations I see are of the standard CRUD fare; but a convenience API to also return the linked Accounts (if they are Accounts) would save from a couple trips back to the servers.

Thanks, Mike

__

— Reply to this email directly, view it on GitHub https://github.com/stellar/stellar-protocol/issues/34#issuecomment-2408437225, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARSULL264BAXDFTC2HVYLDZ3DEYBAVCNFSM6AAAAABP2E4SZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYGQZTOMRSGU . You are receiving this because you were mentioned.Message ID: @.***>

[Taylorman3]

Hi all,

I'd really like to formally link accounts and assets, especially into hierarchies. Think of something like a Chart of Accounts, Parts List / Bill of Materials, Purchase Order, Paper Portfolio, or Index Fund.

This would be a new object type that links two addresses or assets in the system via a from/to. The two link fields could done as "trust_lines" (a from line and a to line). Setting the AssetCode to "" or null would represent an account link, otherwise an asset.

This object has "type" and "name" strings and Managed Data fields for properties of the "relationship". Using this "Link" object is completely user defined and has no formalized in-system meaning.

The operations I see are of the standard CRUD fare; but a convenience API to also return the linked Accounts (if they are Accounts) would save from a couple trips back to the servers.

Thanks, Mike

__

Okay