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
DSNP Announce Spec #8
Conversation
pages/DSNP/DSNP-Announce.md
Outdated
|
||
| field | description | type | | ||
|-------|-------------|------| | ||
| from | Social Identity From Address | address / uint160 / bytes20 | |
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.
- Should we have this here?
- Should we name it something different?
- Should it use the Ethereum address type or do we want to make it generic bytes?
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.
I happen to like the convention either of from
or fromAddr
as a name.
If it's generic bytes, then how does it get mapped to a social identity contract?
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.
I tried out the name dsnpFrom
and standardized the prefixes. Thoughts?
In Solidity address, uint160, bytes20 are all synonyms. The connection would likely come as part 2. The identity interface likely will be required to implement https://eips.ethereum.org/EIPS/eip-1271 that would allow for verification at the level of the announcing contract and the end user.
Likely that will also require that the signature (bytes32) be included as a core log level data point.
34b8c2d
to
48a6ed3
Compare
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.
YUSS
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.
With respect to labeling address types, let's just say "address" in the type and make a note at the top about address/uint160/bytes20
Also I think it would be good to have a short description of what the Announce contract is meant for.
I think I still prefer the "route" idea but there are good non-conflicting things in here that would go in #11 .
|
||
### Announce Requirements | ||
|
||
| Interface | Required | |
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.
Also I like this section. Maybe we should have in the spec template too.
Problem
Users of DSNP need a way to publish messages in a standard way
link to Pivotal Tracker #23177049245
Solution
A separate interface for creating an DSNPMessage event that announces a new message.
Change summary: