DRAFT: Peer Endorsements. #31
Conversation
|
Do we want to include the ability to send parameters (your peerID, a list to retrieve, etc.) to customize the data returned? |
| { | ||
| "name": "standard", | ||
| "description": "A peer that has been vetted by BazaarCo", | ||
| "badge": "https://bazaarco.example.com/standard_badge.png" |
There was a problem hiding this comment.
Since the types are so different from each other, should they each have a link? I can imagine some providers would want a page, or a section of a page, for each one.
cpacia
left a comment
cpacia
left a comment
There was a problem hiding this comment.
Should also allow for this to be seeded on IPFS/IPNS not just use an HTTP endpoint.
Also, I don't see anything authentication information. In the example "BazaarCo" is vouching for peers. But who is BazaarCo? Is it expected to be the owner of the endpoint. Who is this owner and why should they be trusted.
There should probably be a peer ID and signature in the data such that we can tie this data to an OB identity not just an SSL cert.
Finally I don't see a timestamp. We'd want one so that we can publish later copies that invalidate the previous versions if someone needs to be removed from the list.
Might even want a formal revocation process.
| - `types` is an array detailing the types of endorsements being offered. | ||
| - `name` is the name of the endorsement type. | ||
| - `description` is a brief explanation of what this type represents. | ||
| - `badge` is a URI pointing to a badge icon to display on endorsed listings and profiles. |
There was a problem hiding this comment.
Should accept/use IPFS image links
ghost
force-pushed
the
TS_peer_endorsements
branch
from
4487425 to
ecaa265
Compare
3 participants
Proposal for enhancements to OBIP 8.