Add users

[auryn-macmillan]

Description

This PR adds a user entity to the subgraph. User's can have both a default profile, along with publication specific profiles associated with the same address. Profiles include these properties: id, displayName, profilePicture, link, twitter, github, permissions, articles, and publications.

Implementation

A new entity, User, is defined in the schema.

Accounts should be able to create and modify their user profile by calling the Poster contract with a user/update action.

Accounts should be able to delete their user profiles by calling the Poster contract with a user/delete action.

Additional Context

The user entity will be used initially to add richer profile information for authors. However, any user can create a profile and these could later be exposed in the app in a number of ways (likes, comments, reactions, patronage, etc).

[asgeir-s]

Nice :)

Two ideas that came to mind:

1. We could perhaps have a list of a type called social that has a key (for instance, twitter or github) and a value (username) as a replacement for the service-specific attributes like twitter, github, etc.?
2. Perhaps the link attribute could be a list of links also with a key/value type?

For future proofing and to not assume the services used (now and in the future). We don't need to use the extra functionality now but perhaps have the data structure ready.

Edit: thinking about it again, this is probably not important for the indexed data, but more something to consider for the actual actions sent to Poster.

[auryn-macmillan]

For future proofing and to not assume the services used (now and in the future).

Yeah, I thought about this approach as well. Was considering a metadata field (json formatted key-value string), rather than separate fields for Twitter, Github, URL, etc. But figured that the app would probably need to be somewhat opinionated on this anyway, so wasn't sure that we gained much with this approach.

That said, this approach could perhaps enable user-defined metadata.
Perhaps metadata is an array of json objects. There are some that are officially supported, which might render a little better. Things like twitter profiles. And others that are essentially just a title and content (maybe it renders as a link if it can be parsed as such).

Somethign like this, for example.

"metadata": [
  {
    "title": "Twitter",
    "content": "@auryn_macmillan"
  },
  {
    "title": "Homepage",
    "content: "https://link.to.some.page"
  }
]

I also like this because it doesn't enshrine other services at the subgraph level.

[asgeir-s]

That said, this approach could perhaps enable user-defined metadata. Perhaps metadata is an array of json objects. There are some that are officially supported, which might render a little better. Things like twitter profiles. And others that are essentially just a title and content (maybe it renders as a link if it can be parsed as such).

Somethign like this, for example.

"metadata": [
  {
    "title": "Twitter",
    "content": "@auryn_macmillan"
  },
  {
    "title": "Homepage",
    "content: "https://link.to.some.page"
  }
]

I also like this because it doesn't enshrine other services at the subgraph level.

I like this approach, where we don't enshrine specific services. But do you mean saving it as a JSON formatted key-value string in the subgraph or in the action sent to Poster?
If you mean in the subgraph, is it because we should accept any format in the metadata list? Shouldn't it need to have the title and content keys?

[cedricwaxwing]

I also like the metadata approach, but maybe a simpler solution would be to just allow markdown (or ideally rich text converted to markdown) in a description field and the user could list whatever links they wish in the description. That way they don't need to know correct JSON syntax and we don't need to make any assumptions here.

I'm John Smith. I write about DAOs and I like anti-fragile hyper-structures.
Twitter: [@johnsmith](https://www.twitter.com/johnsmith)
Web: [johnsmith.com](https://www.johnsmith.com)

[auryn-macmillan]

I'd prefer to have it be json formatted, for consistency and to make it more easily machine readable.
UI similar to the ENS app could allow users to add custom records.