-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add USER data model architecture #166
Open
ctindogaru
wants to merge
1
commit into
near-daos:main
Choose a base branch
from
ctindogaru:user_data_model
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,67 @@ | ||
> NOTE: The following is implementation examples for discussion on future models for DAOs | ||
|
||
## User Data | ||
```rust | ||
pub struct ComposableUser { | ||
pub attestations: LookupMap<AttestationUuid, Vec<Attestation>>, | ||
pub attributions: LookupSet<Attribution>, | ||
// User approved list of accounts they allow to submit attestations or attributions on this account. | ||
// Default could be set with preferences, to either always allow new or always require approval | ||
pub notaries: LookupSet<AccountId>, | ||
// Allows user to control who & types of data allowed to be stored | ||
pub preferences: UnorderedMap<Hash, Vec<u8>>, | ||
} | ||
``` | ||
|
||
|
||
## Attestation Data | ||
```rust | ||
/// Attestations are signed data that can be proven by some type of cryptographic signature to verify its authenticity. This enforces portability for other entities to validate the source of some attestation. | ||
/// REF: https://github.com/ethereum-attestation-service/contracts/blob/master/contracts/IEAS.sol | ||
/// NOTE on EAS: Attestation schema is based on an attestation + registry system and does not allow for fluid data movement. | ||
/// Additional fields below do not allow attestation registry or contract, but rather allow computed verification to live at or accessible to the entity proving the attestation. | ||
/// This is done with a combination of a proof, signature type & inputs (can even be shared secret based or salted) | ||
pub struct Attestation { | ||
// A unique identifier of the attestation. | ||
pub uuid: String, | ||
// A unique identifier of the AS. | ||
pub schema: String, | ||
// The recipient of the attestation. | ||
pub recipient: AccountId, | ||
// The attester/sender of the attestation. | ||
pub attester: AccountId, | ||
// The time when the attestation was created (Unix timestamp). | ||
pub time: u128, | ||
// The time when the attestation expires (Unix timestamp). | ||
pub expirationTime: Option<u128>, | ||
// The time when the attestation was revoked (Unix timestamp). | ||
pub revocationTime: Option<u128>, | ||
// The UUID of the related attestation. Used on delegated attestations | ||
pub refUUID: Option<u128>, | ||
// Custom attestation data. | ||
pub data: Option<Vec<u8>>, | ||
|
||
// Defines the cryptographic signature for validating the attestation proof, EX: ECDSA | ||
pub signature_scheme: String, | ||
// a value that can be computed using the specified signature engine in combination with attestation data | ||
pub proof: String, | ||
// additional context for any given attestation | ||
pub metadata: Option<Vec<u8>>, | ||
} | ||
``` | ||
|
||
|
||
|
||
## Attribution Data | ||
```rust | ||
/// Attributions are unsigned free-form data that allow entities to give where helpful. Think of this like a tag or nickname - a non-crucial piece of data, which can aid in usage of specific systems (EX: filtering). | ||
pub struct Attribution { | ||
pub name: String, | ||
// The attester/sender of the attestation. | ||
pub attester: AccountId, | ||
// Custom attribution data. | ||
pub data: Option<Vec<u8>>, | ||
// additional context for any given attribution | ||
pub metadata: Option<Vec<u8>>, | ||
} | ||
``` |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this might be just me, but these names are not very intuitive. What attestations should represent? What attributions should represent? Why do we need notaries etc?
Maybe I'm not understanding the purpose entirely, but everything seems over-engineered.