Avoid a need to confirm every DevHub post/like through a Wallet

[frol]

Is your feature request related to a problem? Please describe.

There are two problems at the moment:

1. In order to post a new idea/solution/reply on DevHub or like a post on DevHub users are prompted to sign a transaction through a Wallet since we make a function call on the DevHub contract. This is invasive and breaks users' flow, and they are more hesitant with responding/linking.
2. DevHub cross-posts top-level posts under its own Social Feed, and comments and likes left there are not displayed on DevHub.

Describe the solution you'd like

Use SocialDB posts as the main source of truth to merge two worlds.

I suggest that posting on DevHub will create a regular SocialDB post visible on the feed to everyone who follows the author of the post, and the DevHub indexer would catch those posts and publish references to them to the DevHub contract.

This way we achieve the following:

• Support of fast-auth (free transactions for newly onboarded users)
• No interruptions while using DevHub as likes and posts are submitted to SocialDB using a function-call access key that the BOS gateway holds, and it does not need to redirect to Wallet to sign a transaction
• More engagement as users posting to DevHub will also post to their own feed and their followers will notice and participate in the discussions
• More likes (it would be a no-brainer)

Describe alternatives you've considered

We may use SocialDB for the posts and avoid feed, but we won't benefit from users broadcasting knowledge themselves.

We may stick to using our own contract and sync missing likes and comments to DevHub, but that won't remove the friction from the user experience.

Additional technical context

In order to post to Social Feed, users basically override <username>/post/main, so when you look at the Post component props, https://near.social/#/mob.near/widget/MainPage.Post.Page?accountId=root.near&blockHeight=92478864, notice blockHeight in the URL - the component will basically make a function call to get the data from RPC at that particular historical moment, as SocialDB contract does not store all the posts in its storage, it overrides the data with each new post/comment.

Just for reference, Here is the comment response on the Feed, and here is like.

There is an index key that needs to be properly constructed, and I have not looked into it in more detail.

Here are the features that we need to take into account:

Post creation

As I mentioned before, I suggest we call a set function on SocialDB with:

{
  "<author-account-id>": {
    "post": {
      "main": "MESSAGE"
    },
    "index": { /* figure out how to construct it properly and potentially add DevHub-specific properties */ }
  }
}

It is worth noting that "MESSAGE" might be not only the message itself, but also a link to the DevHub thread discussion as Social Feed does not support nesting (see below).

Reply through DevHub

I believe that each reply should be just another Social Feed post (not a comment), similar to how it worked on Twitter when users imitated threads and retweets ("RT") before they got integrated into the UI. DevHub replies should look like regular posts on Social Feed, but I would add a link to the parent post on DevHub and to the post in the thread on DevHub.

Reply through Social Feed

Comments on Social Feed should be just picked up as comments to the relevant post on DevHub by the indexer.

Nested responses

As mentioned above, I see DevHub posts to be represented by individual posts on Social Feed and in the message itself there should be a link to the DevHub thread. DevHub indexer would catch such posts and add them to the DevHub contract.

Post editing

Social Feed does not support editing, so we will need to simulate that somehow. We might post edits as diffs into the comments (potentially try to hide in spoilers, but spoilers are not supported by Social VM).

@dev-hub.near Apply the change to the original [message](#link-to-DevHub-post).

```
-#old-label #x
+#new-label #x

-Old text
+New text
```

Permissions to edit posts

I think it will be up to the contract to decide whether accept the edits or not while diffs can be commented on Social Feed by anyone and we cannot restrict that.

Task Breakdown

This ticket is a spike. It expects to take one engineer 1-2 week to complete each one of the milestone.

Milestone 1. Proof of concept implementation on challenging features

First we want to ensure the most challenging part of SocialDB based approach is doable. Tackle and figure out technical difficulties in advance. If it's not feasible we can plan early and in the worst case terminate this plan. From discussions with @frol we think the most challenge parts to implement are:

• Simulate post editing with diff in comments
• Plan to migrate existing posts stored in contract to SoicalDB.

So let's experiment on these features first.

Milestone 2. MVP of all features mentioned above

By the end of this milestone, user should be able to do everything with post as they can do in current DevHub board. It includes write, read, edit, reply, like, labeling, types and search posts, but doesn't include community features.

Milestone 3. Migrate existing posts to new one

This milestone is about actually migrating the data from existing contract to SocialDB. Ideally Old posts should still comes from the user's account, but given we cannot represent user's account to batch create user's all history posts, a bot account that grant user's ability to edit would be acceptable. UX details is upon further discussion.

Milestone 4. Integration and merge to production

By this milestone we consider complete this task. All post related functionalities in milestone 2 and all history posts should be deployed in production. User should be automatically interact with the SocialDB posts instead of DevHub posts. Note the scope of this spike doesn't include community in SocialDB, which will be our next step.

[frol]

Extra technical notes:

1. We may use SocialVM Index API instead of implementing a custom indexer
2. We may also use SocialDB feature that includes blockHeight of the last change to its keys (get function has configuration option to enable that) to recursively fetch posts one at a time

[ailisp]

It's a great proposal and comprehensive plan. Adding one requirement: to migrate existing posts to SocialDB. We may start an experimental prototype for this.

[ailisp]

Hi @frol ! I'm planning for next two week's milestone. I'd like to fit one research task to experiment a PoC of SocialDB based DevHub. It's not possible for one engineer to implement the whole PoC in two weeks. So I decide this task to focus on most challenging problem in SocialDB based DevHub. Which one in your opinion is most challenging? IMO it's post editing and permission by contract.

[frol]

post editing and permission by contract.

@ailisp I agree, those are the most challenging ones

[frol]

I add “bug” label here as on near.org gateway, using free accounts created by Fast Auth cannot interact with DevHub, and there is no error, it just get stuck when you try to sign a transaction. It can/should also be addressed on the gateway as well, but we may just as well get it solved by migrating to SocialDB

[ailisp]

Will see the result from tomorrow's meeting, and if we can have native post editing and permission implemented on Social DB side, milestone 1 & 2 will be significantly simplified

[petersalomonsen]

@ori-near this is the issue we talked about last thursday right, that I could look into?

[ori-near]

@petersalomonsen Sure, but you may want to chat with @frol or @ailisp to make sure they're aligned on any technical direction we choose here.

[petersalomonsen]

Will see the result from tomorrow's meeting, and if we can have native post editing and permission implemented on Social DB side, milestone 1 & 2 will be significantly simplified

What was the conclusion from this meeting @ailisp ?

I'm also exploring the possibility of being logged into multiple contracts, which might even mean additions to Social VM, but I think this is also something needed in other use cases. If the VM could support setting up / using multiple keystores, and select which one to use for each call, then it would be possible to interact with multiple contracts without wallet confirmation each time. And also data would not have to be migrated in this particular case.

[ailisp]

@petersalomonsen Discovery team proposed that instead of trying to migrate DevHub contract posts to SocialDB, we together build compatible or adapter layer that index DevHub contract posts to be discoverable on near.org. Later they'll make it the standard interface to make App-specific posts & groups compatible with near.org so that will work for every BOS app. More details is WIP

I think this approach will significantly reduce the migrating data effort and fit DevHub post feature to SocialDB post (edit, nested, label) etc. But this approach will not address FastAuth support, which we need to check their roadmap for general contract support. Your proposed VM with multiple keystores could be a great solution to this problem.

[petersalomonsen]

Great to hear @ailisp ! I've elaborated a bit more on my multiple keystore approach in this devhub post: https://near.social/devgovgigs.near/widget/gigs-board.pages.Post?id=1033

[petersalomonsen]

Also note that this feature also was requested for near-api-js some time ago: near/near-api-js#838

[ailisp]

@petersalomonsen This idea is awesome! It can avoid the need to confirm every DevHub interaction, once implemented your proposed in wallet selector. Could you make a PR there?

For fastauth, we still need to figure out let the proxy account make a contract call to arbitrary contract besides social db.

[petersalomonsen]

Sounds good @ailisp . I will start preparing a PR for the wallet selector then!

BTW. should we split this issue into two? What I will look into for the wallet selector will fix what the title of this issue is about, but does not address the second "sub-issue" here about picking up likes from the social feed. Maybe that part could be moved to a separate issue?

cc @ori-near

[ailisp]

Yep, splitting into two issues is reasonable

[ori-near]

Hi @petersalomonsen – Please feel free to split into tickets and add a reference to both tickets for easy discoverability. Thank you!

[petersalomonsen]

@ori-near I've added a new issue for the connection to the social feed, but I've suggested a new approach as you can see. Not sure if that has been considered.

[petersalomonsen]

I started some work in my own branch ( https://github.com/petersalomonsen/wallet-selector/blob/feat/multiple-local-keys/packages/my-near-wallet/src/lib/my-near-wallet.spec.ts#L256 ) of the wallet selector, implementing a PoC for multiple keystores.

But then I discovered this PR here: near/wallet-selector#811

And it seems at first glance that the multi-sign-in feature is actually trying to solve this, and it's implemented according to a specification that I see @frol have been involved in. So maybe better to look at the PR that's already there for the wallet-selector?

[petersalomonsen]

For my current work in the wallet selector, I'm now able to post and like without confirming with the wallet, but the editor is not closed, and the likes are not displayed without reloading the page. This is because today we have no callback handler for transactions in the VM. I've added an issue for this NearSocial/VM#105, and it seems like there's already an ongoing PR for it.

Here's a demo of the current status at this point: https://youtu.be/DVoZK5CJ2uE

[frol]

@petersalomonsen Wait, how does that work? Is it Sender Wallet / Meteor Wallet flow? You still need to confirm it with a wallet, right? It is just not captured in the recording as it was in a separate window, is that the case?

Pagoda team will release several features in 2 weeks on near.org gateway that will let users to have a limited access key to DevHub's contract, and as such users will be able to skip this confirmation after confirming the first interaction, so onCommit makes sense, and they will also improve FastAuth, so with that the first problem identified in this issue description should be resolved, and the second issue is currently also at discussion level with another Pagoda team, where we want to consider how global feed is generated in the first place, so it can potentially does not depend only on SocialDB, but can pick up new posts from any contract out there.

That said, I want to close this issue as "will be resolved in a different way by another team"

[petersalomonsen]

Thanks for feedback @frol

The Proof Of Concept here is implemented for mynearwallet, and is based on that you add another keystore for each contract you want to interact with without wallet confirmation ( like you see in the video here: https://youtu.be/ocZKP2-Lxes )

So there is no wallet confirmation in a separate window, in the localstorage there is a keystore with a function access key for the DevHub contract ( that was added by calling the addContractConnection method that you can see here https://github.com/near/wallet-selector/pull/887/files#diff-a5f9f24a017d7cfc607d1374e5cb05560b792b8f93d15e13ae6a13a9b29f36a8R177 ).

But if there are already better plans for solving this, then thanks for letting me know. Better to put my efforts here on hold then ( as it involves quite a bit of work ).

[frol]

@petersalomonsen I believe that signInMulti is not the right target to pursue when it comes to BOS (at least, not right now). It is fine to users to start with adding a limited access key to social.near via "Sign In", but BOS should be able to add a limited access key when a user interacts with DevHub contract. Similarly to "Don't ask again for saving similar data by near/widget/v1.LikeButton", there should be "Don't ask again for saving similar data by devgovgigs.near/widget/Post", which will request user to add a limited access key in addition to the regular action, and then in subsequent calls, it should be able to just use that key to sign transactions from the gateway without a need to go through the wallet experience.

I have heard that Pagoda is working on such solution for near.org gateway, but we need to clarify when it will be released.

[petersalomonsen]

@frol I also came to that same conclusion regarding signInMulti as you can see from my comment on that feature.

The solution you describe with adding a new limited access key when interacting with another contract than social.near( DevHub in this case ), is exactly what I've implemented.

In my workspace, I also have a useEffect ( see screenshot below ) hook that calls the addContractConnection method I have in my draft pull request for the wallet-selector.

For now (for simple demo purposes) is just hardcoded to act after any interaction with the wallet, and then add an access key to my devhub contract. But the plan here was to detect what contract that had been called, and ask if you wanted to store an access key for that contract locally.

[petersalomonsen]

Now that entering a password have been introduced in MyNearWallet, having to confirm with the wallet has become even more annoying.

[petersalomonsen]

Picking this up again, and preparing to use with our web-component based test gateway, I've created an example on integrating the wallet-selector with a "vanilla" JS web app:

near/wallet-selector#1011

[petersalomonsen]

A related issue that will also close this one if solved: NearSocial/VM#148

[petersalomonsen]

There's a preview URL in here NearSocial/VM#156

[petersalomonsen]

Depends on NearSocial/VM#156 which is currently in review

[petersalomonsen]

@ori-near Please follow updates on the review process here: NearSocial/VM#156 (comment)

And also feel free to test the preview environment you find in the Pull Request. Would appreciate any feedback on the user experience.

[petersalomonsen]

Made some adjustments after some comments on NearSocial/VM#156 (comment). I believe we are quite close now, but waiting for feedback if there are more adjustments needed.

[petersalomonsen]

@ori-near @frol @ailisp In addition to My Near Wallet, now it's also tested with Here, Meteor and Sender. Here's my summary: NearSocial/VM#156 (comment)

[petersalomonsen]

@ori-near Please follow the progress here: NearSocial/VM#156 (comment)

[frol]

This is going to be resolved with the next release of BOS VM with NearSocial/VM#156, you can already test it live on https://dev.near.social