Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
frol opened this issue May 26, 2023 · 35 comments
Closed

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

frol opened this issue May 26, 2023 · 35 comments
Assignees
Labels
bug Something isn't working enhancement New feature or request spike A research ticket

Comments

@frol
Copy link
Collaborator

frol commented May 26, 2023

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
Copy link
Collaborator Author

frol commented May 28, 2023

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
Copy link
Collaborator

ailisp commented May 30, 2023

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
Copy link
Collaborator

ailisp commented Jun 9, 2023

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
Copy link
Collaborator Author

frol commented Jun 9, 2023

post editing and permission by contract.

@ailisp I agree, those are the most challenging ones

@frol
Copy link
Collaborator Author

frol commented Jun 11, 2023

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
Copy link
Collaborator

ailisp commented Aug 10, 2023

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
Copy link
Collaborator

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

@ori-near
Copy link
Collaborator

@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
Copy link
Collaborator

petersalomonsen commented Aug 11, 2023

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
Copy link
Collaborator

ailisp commented Aug 12, 2023

@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
Copy link
Collaborator

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
Copy link
Collaborator

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

@ailisp
Copy link
Collaborator

ailisp commented Aug 14, 2023

@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
Copy link
Collaborator

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
Copy link
Collaborator

ailisp commented Aug 14, 2023

Yep, splitting into two issues is reasonable

@petersalomonsen petersalomonsen self-assigned this Aug 14, 2023
@petersalomonsen petersalomonsen moved this from 🆕 Triage to 🏗 In progress in [OLD] NEAR Dev Hub Board Development Aug 14, 2023
@ori-near
Copy link
Collaborator

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

@petersalomonsen
Copy link
Collaborator

@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
Copy link
Collaborator

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
Copy link
Collaborator

petersalomonsen commented Aug 26, 2023

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
Copy link
Collaborator Author

frol commented Aug 26, 2023

@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
Copy link
Collaborator

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 ).

@petersalomonsen petersalomonsen moved this from 🏗 In progress to ❌ Blocked in [OLD] NEAR Dev Hub Board Development Aug 27, 2023
@frol
Copy link
Collaborator Author

frol commented Aug 28, 2023

@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
Copy link
Collaborator

@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.

image

@petersalomonsen
Copy link
Collaborator

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

@petersalomonsen petersalomonsen moved this from ❌ Blocked to 🏗 In progress in [OLD] NEAR Dev Hub Board Development Nov 17, 2023
@petersalomonsen
Copy link
Collaborator

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

Image

@petersalomonsen
Copy link
Collaborator

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

@petersalomonsen
Copy link
Collaborator

petersalomonsen commented Nov 25, 2023

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

@petersalomonsen
Copy link
Collaborator

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

@petersalomonsen
Copy link
Collaborator

@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
Copy link
Collaborator

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
Copy link
Collaborator

@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)

@ori-near ori-near moved this from 🆕 Triage to 👀 In review in 🚀 DevHub Products Dec 20, 2023
@petersalomonsen
Copy link
Collaborator

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

evgenykuzyakov added a commit to NearSocial/VM that referenced this issue Jan 8, 2024
…ccess-keys

Support multiple access keys in the VM. Allows widgets to request a function access key to a custom contract by issuing a regular transaction, the following transactions from the widgets will not require a wallet confirmation if the user approves that.

Preview URL: 

https://psalomobos.near.page/devhub.near/widget/app

Or see a demonstration video here:

https://youtu.be/CuwWv1zAKf4?si=lBUi9kXxRrhVjv-s

resolves #148 and NEAR-DevHub/neardevhub-bos#137
@frol
Copy link
Collaborator Author

frol commented Jan 28, 2024

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

@frol frol closed this as completed Jan 28, 2024
@github-project-automation github-project-automation bot moved this from 👀 In review to ✅ Done in 🚀 DevHub Products Jan 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request spike A research ticket
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

4 participants