-
Notifications
You must be signed in to change notification settings - Fork 22
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
Comments
Extra technical notes:
|
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. |
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. |
@ailisp I agree, those are the most challenging ones |
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 |
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 |
@ori-near this is the issue we talked about last thursday right, that I could look into? |
@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. |
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. |
@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. |
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 |
Also note that this feature also was requested for near-api-js some time ago: near/near-api-js#838 |
@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. |
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 |
Yep, splitting into two issues is reasonable |
Hi @petersalomonsen – Please feel free to split into tickets and add a reference to both tickets for easy discoverability. Thank you! |
@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. |
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? |
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 |
@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" |
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 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 I believe that I have heard that Pagoda is working on such solution for near.org gateway, but we need to clarify when it will be released. |
@frol I also came to that same conclusion regarding The solution you describe with adding a new limited access key when interacting with another contract than In my workspace, I also have a 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. |
Now that entering a password have been introduced in MyNearWallet, having to confirm with the wallet has become even more annoying. |
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: |
A related issue that will also close this one if solved: NearSocial/VM#148 |
There's a preview URL in here NearSocial/VM#156 |
Depends on NearSocial/VM#156 which is currently in review |
@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. |
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. |
@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 Please follow the progress here: NearSocial/VM#156 (comment) |
…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
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 |
Is your feature request related to a problem? Please describe.
There are two problems at the moment:
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:
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, noticeblockHeight
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: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).
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:
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.
The text was updated successfully, but these errors were encountered: