As a user, when visiting a profile, I want to see the profile info

bfollington commented 1 year ago

Story

As a user, when visiting a profile, I want to see their profile info, including preferred nickname, my petname, pfp, and bio, so I can know who they are, and what they're about.

Feature: sphere profile JSON manifest

We need to define how a user's profile data is persisted and what data is actually relevant. After chatting with @gordonbrander we've sketched a possible solution.

First, the key fields for a user profile:

petname -> entered during onboarding, your @handle
display_name -> optional, your readable name (displayed about @handle like Twitter)
bio -> optional, short plain-text field to give background on a profile
pfp -> optional, URL(?IPFS) that points to a profile image

Our current vision is that preferred petname will be recorded as a header on the sphere.

All other fields would be stored in a memo named (for example) _manifest_, _profile_ or __subconscious giving us a well-known address for grabbing this information (i.e. @ben/_manifest_). This is somewhat inspired by the Github profile system (e.g. I have a bfollington/bfollington repository that captures my bio).

This is a basic key-value associative structure so we could use CBOR as the storage format.

Questions

Should this manifest/profile be subconscious-specific or designed to be consumed by other clients too?
Would a plain-text data format be better?
Does the division of petname as a header and everything else as memo actually make sense?

cdata commented 1 year ago

Should this manifest/profile be subconscious-specific or designed to be consumed by other clients too?

I would suggest: design for it to be Subconscious-specific, but be open to other clients relying on it for their own purposes.

Would a plain-text data format be better?

If we agree on the semantics of a specialized content-type, we can do "clever" things like trascode CBOR to JSON at read time.

Does the division of petname as a header and everything else as memo actually make sense?

I would say so, yes. Another thing to consider is that the relative cost of reading content from a slug compared to reading a header from the root memo that wraps a sphere is significant. In block terms, we only need one block to read a header from the root memo. But, consider what is needed to read values from content:

Root Memo block
↳ Sphere block
  ↳ Slugs HAMT block
    ↳ Average ~2 HAMT node blocks
      ↳ Content Memo block
        ↳ Content block

These blocks are fairly small and once loaded the reads are quite fast, but the relative cost is still roughly 6x to get to a content block. So, for the most optimal outcome we might try to encode as many things as possible as headers on the root memo.

That said, there are advantages to recording profile data as content. The main one I see here is that you can use a CID to refer to the PFP, which can be encoded as an IPLD link when we write the profile data to storage. A PFP referenced as an IPLD link can be picked up and moved around with sphere without us having to interpret block bytes as a user profile (in other words, it's easier to correctly replicate the data when moving it from A to B).

gordonbrander commented 1 year ago

Per our chat with @cdata

Memo body is always bytes. Content-Type is used to determine encoding.
No special access to IPLD in memo body at this time

I like this set of choices. It makes IPLD an implementation detail of the protocol, and the encoding an implementation detail of the app. Two clean shearing layers.

Given that, I personally would lean toward using ordinary JSON as the profile file type. JSON is ubiquitous, readable and editable in plain text.

Swift has great support for JSON through the Codable protocol. We can also sort JSON keys to reduce CID churn https://www.hackingwithswift.com/example-code/language/how-to-sort-the-keys-of-your-json-using-codable

subconsciousnetwork / subconscious