Groups on Near.org

[charleslavon]

Context

This document serves to come to an agreement on a specification for a new "Groups" experience on near.org designed to allow people to create and discover communities around specific topics, interests, projects, governance, etc.

We need

1. A standard for SocialDB groups to support discoverability on near.org and interoperability between dApps; mitigating the compatibility problems which arise when dApps build distinct "posts" and "groups" implementations.
2. To allow a group of users to moderate with sovernity a scope of socialDB limited to the members of the group.
3. All content posted to groups that a user is part of to appear the user’s “Following” activity feed on near.org

Summary

We can leverage the NearSocial schema's intentionally generic, loosely typed top-level objects, along with socialDB's permission model, to create Groups as near subaccounts (e.g. of groups.near) and socialDB namespaces which are publicly viewable to all users and writeable by permissions granted to members of a group.

Detailed Proposal

Allowing a group of users to moderate their own socialDB namespace can be accomplished via two primary contracts:

1. a namespace-permission-managemment contract, deployed at a Pagoda owned address, e.g. manage.groups.near, which provides the following api:

   1. init_socialDB(groupName): creates a function call access key for [groupname].groups.near at social.near
   2. grant_write_permissions(accountId, groupName, namespaces): grants the given accountId write access to the provided socialDB namespaces [groupname].groups.near/[namespace]

2. a sputnikDAOv2 factory deployed at groups.near. Using a DAO as the binding agent between group members provides the foundation for shared ownership of a near social namespace, voting, distinct roles, and shared ownership of assets.

   1. Alice desires to start a community on near.org. She engages with our Groups component, clicks Start a Group, and is presented with a form requesting a groupName (must be unique), description, links, and tags. Alice is the DAO's initial member and the only council member (i.e. the group's owner). All fields except for the groupName are mutable after creation.
   2. Upon submitting the form, Alice is prompted to approve a transaction to call create at groups.near.
   3. A successful call to create results in a Sputnik v2 DAO contract being deployed at [groupName].groups.near and a cross-contract call to init_socialDB and grant_write_permissions('alice.near', groupName, ['post', 'widget']) at manage.groups.near
   4. Subsequently, Alice is prompted to invite others to the group and she is presented with the non-required option to assign any of the group's default roles to each invitee.

   	"roles": [
       {
         "name": "all",
         "kind": "Everyone",
         "permissions": [],
         "vote_policy": {}
       },
       {
         "name": "council",
         "kind": { "Group": ["alice.near"] },
         "permissions": [
           "*:Finalize",
           "*:AddProposal",
           "*:VoteApprove",
           "*:VoteReject",
           "*:VoteRemove"
         ]
     	 },
         {
         "name": "moderator",
         "kind": { "Group": [] },
         "permissions": [
           "*:AddProposal",
           "*:VoteApprove",
           "*:VoteReject",
           "*:VoteRemove"
         ],
         "vote_policy": {}
       },
       {
         "name": "admin",
         "kind": { "Group": [] },
         "permissions": [
           "*:AddProposal",
           "*:VoteApprove",
           "*:VoteReject",
           "*:VoteRemove"
         ],
         "vote_policy": {}
       }
     ]
   

   1. Alice is prompted to approve a transaction calling grant_write_permissions(accountId, groupName, ['widget', 'post']) for each invited moderator and grant_write_permissions(accountId, groupName, ['post']) for every other invitee.

3. The above contracts provide the core components of group functionality: self-governed management of a group's socialdB namespace and managing the addition and removal of individuals from a group. We can build upon this with a BOS component similar to near/widget/ComponentDetailsPage. Where a modified instance of this component is created for each group; modified to restrict UI affordances to users with the requisite DAO role, e.g. limiting content moderation actions to group members with the 'moderator' role. Also modified such that the desired product requirements are satisfied.

Open Questions

1. How does this address the interoperability concerns of 'posts' between existing dApps like Near Hereos and DevHub?
   1. It doesn't go that far. This proposal is focused on groups. Adding Post compatibility is being considered in the technical designs for content streams and content moderation on socialDB.
2. How to implement posts editing? It is an orthogonal problem to communities, as posts editing is not available for regular NEAR Social posts as well, but with communities, it is an even more important feature to have as posts may need some corrections, especially the longer ones (such as ones we expect on DevHub)
3. How to make this experience smooth from BOS? Users would need to sign transactions from their accounts to community account DAO contracts, so they would either need to sign every single request with a full access key or have several limited access keys - one per community they want to post to.

Resolved Questions

[nearbuild]

Isnt deploying a subaccount cost intensive?

[charleslavon]

@nearbuild yes it is. This DAO-based approach would require sponsorship similar to how FastAuth accounts are sponsored with funds restricted to near.social interactions.

[frol]

@charleslavon Thanks for putting this proposal together! I think it is a great starting point and I completely support the composability and use of DAO contracts. I want to re-emphasize the following aspect, which I feel might be missed by most of the readers not familiar with how posts work in NEAR Social:

Communities are just new accounts on NEAR Social, which would grant write access to their SocialDB <community>.near/post/main key to other NEAR accounts, so to post on behalf of a community one would make a function call on social.near like this:

set({
  "data": {
    "my-community.near": {
      "post": {
        "main": "Frol's post on behalf of My Community"
      },
      "index": {
        "post": "{\"key\":\"main\",\"value\":{\"type\":\"md\"}}"
      }
    }
  }
})

According to SocialDB implementation, I can set someone's key in SocialDB if my account or access key is granted that permission.

If we model communities around accounts, we get NEAR Social global feed, followers subsystem, community page (profile page), and many other features "for free" (no need for changes in a number of services out there).

Resolved challenges are:

1. How to bootstrap a new community account while authenticated with your current NEAR account? Factory is needed (see groups.near factory explained above)
2. How to manage access to metadata? If community metadata is just a regular NEAR Social profile metadata, those are just key-values in SocialDB, instead of granting direct access to those keys, I would still suggest using DAO contract to propose-approve changes in a transparent way.
3. How to manage access to make a post on behalf of the community? Again, post is just a key in SocialDB that is updated with every new posting, so similarly to (2), we can manage that through the DAO contract (there will be a bit of cross-contract calls, but overall, should be fine)
4. How to enable resharing by community? Again, re-sharing is just an update to the index key, so that could be managed by a DAO contract (same as in (2) and (3))

If the DAO contract is flexible enough, it could allow both strict posts pre-moderation and also a no-censorship type of communities.

To summarize, in order to post on behalf of a community users would need to submit a DAO proposal as a function call to the community account instead of social.near:

add_proposal({
  "description": "Publish this post on behalf of the community",
  "kind": {
    "FunctionCall": {
      "receiver_id": "social.near",
      "method_name": "set",
      "args": {
        "data": {
          "my-community.near": {
            "post": {
              "main": "Frol's post on behalf of My Community"
            },
            "index": {
              "post": "{\"key\":\"main\",\"value\":{\"type\":\"md\"}}"
            }
          }
        }
      }
    }
  }
})

Depending on the DAO configuration, this proposal might immediately resolve into a cross-contract call to social.near or wait until it is approved.

Not resolved challenges are:

1. How to implement posts editing? It is an orthogonal problem to communities, as posts editing is not available for regular NEAR Social posts as well, but with communities, it is an even more important feature to have as posts may need some corrections, especially the longer ones (such as ones we expect on DevHub)
2. How to make this experience smooth from BOS? Users would need to sign transactions from their accounts to community account DAO contracts, so they would either need to sign every single request with a full access key or have several limited access keys - one per community they want to post to.

[elliotBraem]

I think you may have misread my question. In the example:

If I want to post an Idea to the "BOS Community", then I NEED to either be granted write permissions to the BOS Community Account, or create a DAO proposal for the community account to post?

I'm not unfamiliar with community/DAO managed posts -- we've implemented this many months ago : https://near.org/nycdao.near/widget/NYC -- along with other explorations in how to effectively index posts (by domain, or by key)

It's just that this sounds like: in order for a post to reach a community, it needs to be posted by this community/DAO account -- this is unlike near.social and even posts on DevHub contract; I'm not sure how this solves a problem.

[frol]

It's just that this sounds like: in order for a post to reach a community, it needs to be posted by this community/DAO account -- this is unlike near.social and even posts on DevHub contract; I'm not sure how this solves a problem.

@elliotBraem Let me try to explain it from a different angle.

I suggest community posts to be posted to social.near (SocialDB) under the community account id instead of a personal account id. From SocialDB point of view, top-level keys are reserved for NEAR accounts, so I suggest to create those accounts and let NEAR Social users to subscribe to the posts published by these community accounts.

Community account can make posts from a contract deployed to it. The simplest contract could just whitelist DevHub's contract and thus add_post on DevHub will be in charge of permissions of who can post to a given community, and if the user is allowed to post, DevHub's add_post function will make a cross-contract call to the community account, and that will make a cross-contract call to social.near to set the <community.near>.post.main key. Instead of DevHub's contract, we may have a DAO contract, we may either deploy it separately or right on the community account.

[elliotBraem]

Thank you for the different angle -- it's much more clear. It seems to me that the main issue that this is trying to solve is who is allowed to post; as this moves data ownership to a shared entity rather than the personal account.

I suggest community posts to be posted to social.near (SocialDB) under the community account id instead of a personal account id.

I understand that this is being proposed so users can "follow" a community, but how would you envision the post appearing on your social feed? Would it embed the original accountId? Is there some preprocessing in the post widget to strip out the community account and so it appears like a typical post?

Other things to consider:
What happens if the seed phrase to the community account is lost? Does the community cease to exist? Must an entire community be migrated? And how does that migration work (how do you relay information to the community when their source of information (the account they follow) has been compromised?

[charleslavon]

@elliotBraem @frol thank you both for diving into the details of this discussion. Regarding the below point, while I'd prefer to not couple this effort with the need to define a standard for Posts, there's likely a need to recommend a Post schema that would account for postedBy and postedOn type fields and facilitate migrating DevHub communities to social DB groups and DevHub posts to socialDB group posts.

I understand that this is being proposed so users can "follow" a community, but how would you envision the post appearing on your social feed? Would it embed the original accountId? Is there some preprocessing in the post widget to strip out the community account and so it appears like a typical post?

[frol]

I understand that this is being proposed so users can "follow" a community, but how would you envision the post appearing on your social feed? Would it embed the original accountId? Is there some preprocessing in the post widget to strip out the community account and so it appears like a typical post?

I would take inspiration from Reddit. They strike the right balance between an author of a post and the community it is posted to. We should embed the author in the post metadata and consider also including it in the markdown text of the post itself. Gateways should also update their UI to support community posts or rather posts "on behalf of someone else", like GitHub does when you have a commit with several contributors:

What happens if the seed phrase to the community account is lost?

I suggest community accounts to be locked, no access keys needed, so if upgrades needed, the community contract should have the upgradability methods implemented (DevHub and Sputnik DAO contracts have it, just for the reference).

I believe that we should not define how to do moderation for communities, so the permissions system can be that there is a "community contract" deployed to a community account, DAO contract, or DevHub's proxy - this should not change how the posts will be fetched and displayed (they will still be on SocialDB). It could be even a community of a single owner if someone chooses to have it that way.

The worst that can happen to community is that nobody will be able to post on behalf of that community, and I don't see it as a problem we need to solve here. If needed, all the posts can be re-posted again (though I don't see a reason for that, as all posts are stored on the chain anyway)

[elliotBraem]

Is a group/community an explicit entity owned by somebody, or are they implicit webs of people grouped by common interests?

While I think these are worthwhile solutions to provide features that a group or community may appreciate -- such as some form of DAO governance or community broadcasted messages -- I don't think we need dedicated accounts to represent a group of users and the relationships between them-- we have a social graph for this.

For example, following/subscription are just relationships between nodes in the SocialDB-- a following post feed is a Social.index filtered by accounts described in this graph standard; for example from mob.near/widget/N:

let accounts = undefined;

if (state.feedIndex === "following") {
  const graph = Social.keys(`${context.accountId}/graph/follow/*`, "final");
  if (graph !== null) {
    accounts = Object.keys(graph[context.accountId].graph.follow || {});
    accounts.push(context.accountId);
  } else {
    accounts = [];
  }
}

const posts = Social.index("post", "main", { limit: 100, accountId: accounts }); 

In this excerpt, we first gather all of the account keys I follow, then we filter posts on the main feed by these accounts.
And this concept can be extended from here: I could create a filtered feed exclusive to the people I follow AND follow me back. I could create a filtered feed exclusive to the people I follow, that follow me back, that follow you, that follow you back, etc...

In other words, a group or community can be represented by the mutual connections in the social graph -- those who include one another in a group. This determines the feed of posts that come from a community. Therefore, a community is not a single entity, it cannot be lost, it cannot be compromised; it is resilient and reliant on the members of it.

You can see a working POC in the BOS Hacks submission here and I would recommend reading the prior context, too. It's not a perfect solution, but I think it's a step in the right direction.

[frol]

Is a group/community an explicit entity owned by somebody, or are they implicit webs of people grouped by common interests?

I view communities to be independent entities, like subreddits. I see the benefit of communities in that as a user I don't need to subscribe to all the individuals to learn about some topic (e.g. "Offline NEAR community in Vienna").

community can be represented by the mutual connections in the social graph

This is "friends" concept in social networks, and it turned out to be limiting as people don't necessarily always want to have a mutual connection (e.g. Illia does not follow nearly as many people as he is followed by). "Friends" is not a community, so let's not discuss it here.

[charleslavon]

@elliotBraem We're thinking of Groups as explicit membership based structures organized around common themes/interests.

I'm experimenting to be able to demonstrate how a groups standard in socialDB is essential to support feature parity across gateways, even when gateways may different in specific parts of their implementation, e.g.

• near.org using DAO/subaccount for group features
• near.social not using a DAO/subaccount approach
• All members of a group should receive a notification when some content is published: a new post, a threshold of comment activity, a new member added, a poll created for the group to vote upon, etc

[charleslavon]

Closing this discussion in favor of this enhancement proposal @elliotBraem @frol It would be great to get your feedback on this draft SEP.