Conversation
wesbiggs
force-pushed
the
proposal/DIP-273_Content_Addressing
branch
from
bbce502 to
9332b55
Compare
* Update the definition of DSNP Content Hash to include DSNP CIDs * Change ProfileResource to use bytes, not string, for cid field, in line with Announcement usage * Update Activity Content Hash extension to include CID option * Update various example hashes to use CIDv1 * Update to pre-1.3.0 versioning and sync prerelease changelogs
wesbiggs
force-pushed
the
proposal/DIP-273_Content_Addressing
branch
from
9332b55 to
c571222
Compare
pages/DSNP/Identifiers.md
Outdated
| - CID version: MUST be version 1, in order to distinguish CIDs from simple multihash values in situations where either may be used | ||
| - Hash algorithm: MUST be `sha2-256` or `blake2b-256` | ||
| - Encoding: MUST be `base58btc` or `base32` | ||
| - Codec: MUST be `dag-pb` for data 256*1024 bytes or longer; `raw` for data less than 256*1024 bytes |
There was a problem hiding this comment.
Adding backslash before * helps markdown to disambiguate:
- Codec: MUST be
dag-pbfor data 256*1024 bytes or longer;rawfor data less than 256*1024 bytes
…ported types only. Announcements have been updated to use strings for contentHash and targetContentHash fields.
wilwade
left a comment
wilwade
left a comment
There was a problem hiding this comment.
Everything looks good with the exception of some of the example hashes.
| "hash": [ | ||
| "QmQNHNfHnbgJJ6nK4UPx2VtTUCafAKCbqZJ6ZRYUGjoeFj", | ||
| "2DrjgbGgSsXRhTiBWckoVwBFC6H4qiBWWNumSsRwdUt82YnTdN" | ||
| "bciqgb7tvyyqn6tw4amtdj7funn5ockup6ldrkap4o5ubd77od6awi4y", |
There was a problem hiding this comment.
I'm getting a different value for the hash of the dsnp_whitepaper than this is giving me.
- Perhaps it is the older version of the whitepaper the hash is of?
- Different hash setup that is reading the file differently than I did?
- I tried
sha256sumon mac and a random online hasher.
- I tried
The digest I expected from hashing the file was 0x36d37cf984565f2151ccea050e0bcecf44801b4c89971654c7308dc2338ce7ea
However the digest from this multihash appears to be 0x60fe75c620df4edc032634fcb46b7ae12a8ff2c71501fc776811ffee1f816473
There was a problem hiding this comment.
Yep, my mistake. Will fix.
| "QmQNHNfHnbgJJ6nK4UPx2VtTUCafAKCbqZJ6ZRYUGjoeFj", | ||
| "2DrjgbGgSsXRhTiBWckoVwBFC6H4qiBWWNumSsRwdUt82YnTdN" | ||
| "bciqgb7tvyyqn6tw4amtdj7funn5ockup6ldrkap4o5ubd77od6awi4y", | ||
| "bdyqdua4t4pxgy37mdmjyqv3dejp5betyqsznimpneyujsur23yubzna" |
There was a problem hiding this comment.
Same for this one, so I think it might just be we are using different files.
| | emoji | `BYTE_ARRAY` | `STRING` | `UTF8` | | ||
| | fromId | `INT64` | `INT(64, false)` | `UINT_64` | | ||
| | inReplyTo | `BYTE_ARRAY` | `STRING` | `UTF8` | | ||
| | targetContentHash | `BYTE_ARRAY` | `STRING` | `UTF8` | |
There was a problem hiding this comment.
Note: Confirming on gateway side this is already updated
shannonwells
left a comment
shannonwells
left a comment
There was a problem hiding this comment.
This time for sure
5 participants
Problem
DSNP should provide affordances for finding content that do not rely on a single DNS-based point of failure for content hosting.
More in the original discussion: #273
Solution
Enhance the specification to treat URLs in Announcements as suggestions rather than canonical locations for content.
Provide a simple and well-specified set of hashes and encodings that can be used consistently throughout the protocol.
Use IPFS CIDv1 specifically for locating profiles.
Change summary:
contentAddressfieldcontentHashandtargetContentHashfields.