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

Use Session Ecosystem and Community Fund to Out source Oxen GUI wallet maintenance work to a third party like Cake Lab #66

Open
venezuela01 opened this issue Dec 19, 2023 · 2 comments

Comments

@venezuela01
Copy link

from @jagerman

We don't want anyone's assets to disappear, but there is a technical aspect to this: we really want to be able to eventually drop supporting and maintaining the OXEN chain and OXEN wallets; maintaining them for 10 years is a significant burden, both for dev time, and for SN operator time and effort of needing to keep 20GB+ blockchain data around. I don't think there is any planned "cloud of foof" date, but I also don't think it can go to infinity.

I understand the burden of maintaining Oxen and I appreciate that.

For the Oxen wallet, there are two components: the GUI and the wallet core. The GUI code might fall into dependency hell if it's not constantly maintained and updated. I understand the frustration and distraction that come with maintaining legacy code.

Have you considered outsourcing the GUI part of work?

The Oxen mobile wallet was originally forked from Cake Wallet, which is now cross-platform on Android, iOS, macOS, Linux (beta), supports BTC, BCH, ETH, XMR, LTC, Haven, Nano, and is working on integrating with Zano [1]. If the OPTF pays Cake Wallet Lab some funds to integrate the Oxen core into Cake Wallet, could that be a feasible solution? The Cake Wallet team, already familiar with the Monero codebase and knowing the Oxen mobile wallet was a fork from Cake Wallet, should find it relatively easy to manage the integration of Oxen, so it wouldn't be too costly for them to maintain one more integration.

According to [2], 18.33% of Session Tokens will be reserved for the Session Ecosystem and Community Fund.

Does the community have voting rights on how to use these funds?

Would it make sense for the community to vote on allocating some funds to pay Cake Lab for integrating and maintaining the legacy Oxen wallet at a minimal level? This could begin with paying Cake Lab for 20 hours of consulting to estimate the integration costs, followed by a decision based on a cost-benefit analysis.

[1] https://guides.cakewallet.com/docs/Cryptos/cryptos/

[2] https://oxen.io/blog/session-token-swap-program

@KeeJef
Copy link
Collaborator

KeeJef commented Feb 12, 2024

Oxen wallets will continue to be supported indefinitely, as this is essential for historical Oxen holders to prove their balances for migrating to the Session token. However, we won't be introducing new features for Oxen users; we'll only do what's necessary to stay compatible with hardforks.

Once the migration has occurred i think we should look at centralising control/storage of the Oxen chain, since it will start to become less relevant for purposes of consensus, with most nodes looking at the Arbitrum chain as a source of truth. This might mean we stop forcing Service Nodes to store the chain and just rely on a network of full nodes to store the chain. However we will have to see how this works with the existing transaction validation and consensus systems. Ideally Service Nodes don't need to store 20gb+. I have read previous arguments from @venezuela01 that this is an insignificant amount of space in the grand scheme of things, however space is space and reducing usage would be a good thing

@venezuela01
Copy link
Author

I can see the benefit of not having to store the chain, but from a slightly different perspective:

When a new operator starts a new node, the most time is spent waiting for syncing. This several hours of waiting time can result in a poor experience, especially for new operators, since old operators know how to speed it up. Making chain syncing optional will greatly improve the experience for new operators, making it more inclusive for a potentially wider community.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants