NEAR Wallet is deprecated, is this transition happening fairly and in the best interest of the NEAR ecosytem?

Ecosystem
, ,
1

Hi Everyone

The official NEAR wallet (that was built and used by users as the official wallet of NEAR) is being deprecated (NEAR Wallet is deprecated · Issue #329 · near/wallet-selector · GitHub).

It seems that the official NEAR will transition all their users to MyNearWallet as well as disable a previously available & strategic API kit that was public and supported builders making products on NEAR.

DISCLAIMER - I am still trying to gather more information to understand what is happening, how, and when.

The goal of this post is to bring us all together to confirm what is happening for transparency in the NEAR ecosystem. I am a co-founder of Near Tinker Union NFT and we are currently building out a Wallet for NEAR called Meteor Wallet.

– Wallets are important to the ecosystem –
Wallets are truly important applications of the ecosystem and it’s important we all support healthy competition to make sure the users get the best product or at least options.

I just do not understand the reasoning behind what is happening here and just wondering what other advocates of NEAR think too…

– What seems to have played out between the official NEAR wallet & MyNearWallet –
So as far as I understand, the MyNearWallet Team developed the initial API that the official NEAR wallet used (as an official ecosystem product) and also made that API public to others (ability to import the wallet, get a user list of NFTs etc).

But it seems like they have disabled the API lately, with no communication and we are not sure what is happening…

All the other wallets will now have to spend more resources and time building out an indexer instead of a great product for the people of NEAR.

On the surface level, one could think, they have every right to do that as they developed the initial API, but I just feel how this played out is not in the best interest of the NEAR ecosystem.

–Conflict of interest/concerns?–

  • You have the same team that build the official NEAR wallet which was not for profit but for the good of the ecosystem (they did this with the support of everyone as they were the official NEAR wallet and then leveraged this to then transition the users and disable the tech to their commercial advantage thereafter).

  • You have an API that was developed specifically for the official NEAR wallet and made public to the ecosystem previously that has now just been disabled with no communication (knowing that other wallets build using it)

The same team spun out as an entity to develop this further, but with massive starting advantages (all the users get transitioned across + tech headstart advantage etc → they just take it over and leave all others with nothing)

–Could there be a better alternative?
NEARs goal is to create an open-source platform that accelerates the development of decentralized applications. This move feels like a web2 play…

  • Let users change over to better products in a natural way as they should (not just give one wallet all the advantages from the official legacy product)

  • Leave what was previously available on the API should remain active to support the projects that have built projects using it and to give support to others building that might not have the capacity to build out their own indexer.

  • In order to get users’ list of tokens (FT & NFT), we need to stream all history blocks data (from indexer) into a database and query them, but the cost to maintain such a system (database + validator) is quite costly and timely to setup.

– Current Impact on NEAR –
Most wallets now have broken products and are scrambling…

  • Sender wallet, you cannot view any NFTs etc
  • Meteor wallet: we have had to scramble in our alpha to try to resolve this…

Most wallets that have been trying to build products for the NEAR ecosystem have now will be at a disadvantage by taking away public and strategic API for NEAR to the benefit of the ecosystem.

Not only has MyNearWallet got an unfair starting advantage but also took all competition for a very important application for NEAR backward.

– Call to action –
Anyone who considers themselves an advocate of NEAR and who truly wants the best for this ecosystem and community cannot be ok with what is happening here surely?

Please can we get clarity on what has happened here and let’s try to find the best outcome going forward in the best interest of the NEAR ecosystem?

17 Likes
2

GM Frens!

NEAR Contract Helper (kitwallet endpoint)

The team wanted to apologize for locking this down to just wallet.near.org and mynearwallet.com, we were running into availability issues and had to lock down the api for debugging purposes. We also never expected other teams to be using our APIs for their wallets which was an interesting discovery. We will be sharing more details on the future of the near contract helper for wallet services in a future post but please continue to use this service as you had or feel free to spin up your own contract helper to remove this dependency on our APIs and maintain your own availability metrics.

The current web wallet codebase will be migrated to the MyNEARWallet team, the project will continue to remain open sourced for folks to contribute to or fork as needed.

NEAR Org Wallet Timeline and Plans

The team is planning on sunsetting the wallet functionality on the current web wallet so that it can mainly be a page to recommend places users can create wallets or export their original existing wallet to a new wallet. This will be a phased approach and will not be a sudden sunset of the wallet. More details to come on the phases and timelines.

The NEAR team will not have an official wallet nor will the NEAR Foundation recommend one wallet from our curated list over another but rather will share wallets in the ecosystem that have met our security and product requirements for users to create or use.

If you’d like to add your wallet to the list of curated wallets, we will share more details on how to do this with security and product criterion to get your wallet added to our wallet selector on the current web wallet. More detailed plans on the transition from the current web wallet will be communicated on 8/17.

Wallet Selector

DApps in the ecosystem will be encouraged to use wallet selector to allow their users to select a wallet of their preference. We’ve already engaged several DApps in the ecosystem to migrate to wallet selector so that their users can select from a list of wallets rather than hard coding the current near web wallet.

Hope this provides some much needed clarity and apologies again on the confusion this created.

WAGMI!

8 Likes
4

Thanks for bringing this up. It’s indeed a little disheartening to see insiders spin out with a bit of an advantage. But keep in mind, there was a lot of blood sweat and tears that went into building wallet.near.org into what it is today. Isn’t it up to Pagoda/Foundation to decide how best to divest themselves of running public infra that should be application layer, like we see in the Ethereum community, who no longer run any of their early wallets?

Also, what is the alternative if the NEAR Foundation/Pagoda no longer want to support the NEAR wallet as a public good but also refuse to let a team continue to operate the codebase? We shut down products that work because other ones aren’t ready? Wouldn’t that set the community back?

By the way, the wallet is entirely open source and anyone else can compete with mynearwallet anytime they wish. They just have to run the infrastructure (more on this and indexers at the end).

Now about the API issues. Unfortunately there’s no such thing as a free API. Any developers with a modest amount of experience will know that you never rely on a public API without documentation, usage limits or an API key. It’s just not going to last. In fact, just recently wallet.near.org was down because it was using coingecko APIs for currency rates, and was rate limited.

I’m sorry other alternative wallets stopped working, but they never should have relied on closed APIs that were not public goods, or at least communicated that they needed some alternative sooner. The public indexers and other NEAR repos have warnings all over them about overuse.

See warning: GitHub - near/near-lake-indexer: ETL Indexer implementation

Speaking of NEAR repos. Did you know the indexer and lake framework are given away for free? You just have to pay to run them on your own cloud infrastructure. Here you can index all the NFTs you want. That’s what most of the marketplaces do. So why can’t a wallet team run their own indexers? Or use a legitimate third party solution?

A lot of work went into wallet.near.org and now they’re handing it over to an external team to maintain it. It may not be a perfectly smooth transition, but it’s open source and anyone else can step up and form a team. If the community were thinking undocumented APIs were public goods, that’s a rough one for them because no one explicitly was advertising these APIs for public use. Calling this unfair IMHO is a bit of a stretch.

Bottom line, it’s not pretty, but it’s their right to do what they want with the wallet they built and the associated APIs. But anyone else can have the same APIs running in a day and fully examine and even copy from the wallet.near.org source code.

4 Likes
5

@agileurbanite1 - Thank you for responding timely and providing more context to the situation.
The contract helper has been helping founders do things quicker with fewer resources, so we really do appreciate the work put towards it and it is great to hear that is to remain open source and accessible to all.

It would be greatly appreciated if you could share more details on how we can get added to that list of curated wallets (as far as I know we have integrated with the Wallet Selector recently).

@mattlockyer - I honestly have a huge amount of respect for you and the NEAR Foundation/Pogoda team. Thank you for giving additional info/context to this.

Isn’t it up to Pagoda/Foundation to decide how best to divest themselves of running public infra that should be an application layer

  • I am not sure I would agree with you here. I think Pagoda has an incredible responsibility to be sensitive/accountable to the NEAR community knowing the impact it has on the ecosystem/position it has held.

I understand that API’s will normally have limits, keys etc (I am not a developer, so please excuse any ignorance I may have). I guess what I am speaking about, is more the ethos and mission of what I know we all trying to do here, trying to create the best environment to accelerate the development of decentralized applications.

My understanding is that this API was pretty easily available, which made sense, even if on favorable terms as NEAR should be doing everything possible to support/encourage innovation and make building products easier (which this API has done for many projects - especially in their earlier/MVP stage when founders have limited resources). As our project matures we definitely will be reducing the dependency by running them on our own infrastructure.

I would like to share that it was not an easy decision to post this. I do not want to put NEAR in a bad light or burn any bridges with some of the core/most influential people in the ecosystem (especially as a new project/founder) - but I felt this discussion had to be had to accelerate a fair and clear way forward that is in the best interest of the ecosystem.

Prior to this post:
1.) Our product and many others relied on this API which stopped working (we needed to understand the situation with urgency).

2.) I was honestly concerned about how the transition would play out and if it would be fair.

  • Limited information what available on what was happening (it was not discussed in any public forum it seems).

What I could find was:

In both posts, it mentioned that:

  • Since we are migrating the NEAR Wallet to the My Near Wallet domain(mynearwallet. com)
  • the NEAR Wallet at wallet.near. org is moving to a new domain as My Near Wallet (mynearwallet. com)

To just redirect/change the wallet domain to MyNearWallet would have been a big starting advantage, as users would then just adopt MyNearWallet. It has been confirmed since that the original wallet.near. org domain will be kept as a landing page to showcase the listed ecosystem wallets.

–

The goal of this post was to get clarity/transparency on what was happening and to make sure it is in the best interest of the NEAR ecosystem. I believe this has been achieved. Thank you everyone.

5 Likes
6

All good and I definitely see where you’re coming from. Apologies if my response reads a bit heavy, but it is kind of a tough love, learning moment for all.

I agree 100% with you that this transition was not clear, marketed, brought to a community discussion or smooth. I 50% stand by my comment that it is NF/Pagoda decision and they have the right to do whatever they want, since to some degree their decisions will impact the wider ecosystem.

However, on the points about the APIs, this is where I agree the least. Maybe not 0% agree with you about these APIs should have been available to other builders, but close to 0% and my post details why that is so.

There’s 2 broad aspects that could be discussed here:

  1. open source code freely available
  2. open APIs run as a public good on public infrastructure

IMHO, it’s never ok to rely on (2) for any serious product.

This is NOT a quality you should consider when building a product around an API. Unless the API is documented, with clear limits defined, you’re actually just stealing data and bandwidth from someone else’s infrastructure.

Which brings me back to (1) and the wallet, contract-helper, indexer code. This is all FREE. You simply need to deploy it somewhere. I know for a fact the contract-helper costs less than $5/mo to run, and the indexer which is more complicated approx $100-150/mo.

Not free! But I still strongly feel that it’s time the NEAR community started discussing how to run these things together and share their resources, so we’re not dependent on Pagoda or the NEAR Foundation. There are also other solutions, the Graph, Covalent, etc…

In addition to this, it would be nice to see sustainable business models come out of the community so that we’re not a “grant chain” with a bunch of experiments that are unsustainable.

I want to see more wallets, apps, tokens, NFTs and other assets on NEAR. It’s an incredible platform to build on with probably the best technology in the crypto/blockchain space, no exceptions! We need to take the apps and infrastructure we build seriously though and have many teams focused on reliability and working together on a path to sustainability. That requires a bit more technical and business know how.

We’ll get there, together, this is just a speed bump!

3 Likes
7

Yeah we didn’t expect people to depend on our API that we never documented or disclosed to the public. But since folks are actively using it on testnet AND mainnet. Well we decided to keep it open for now because you know… WAGMI!

Anywho I agree with @mattlockyer here folks can spin up their own contract helper and indexer to maintain their own availability for their customers / users. This has several advantages as you can modify / optimize these APIs to fit your specific use cases and needs. Also the code is open source so happy to receive contributions that will generally benefit everyone so please file issues and open PRs!

Our team will share more info on our plans for this API on 8/17 but in the interim feel free to continue to use it as you have been. Also, @mikedotexe duly noted that 8/17 seems super far away so let me circle back with our team to see if we can announce some things sooner than later like this API issue.

Keep BUIDLing Frens!

5 Likes
8

Hi @mattlockyer, I’m also one of the fans of all the work you are doing for NEAR. Thank you :slight_smile:

Regarding your points on using wallet APIs:

Which brings me back to (1) and the wallet, contract-helper, indexer code. This is all FREE. You simply need to deploy it somewhere. I know for a fact the contract-helper costs less than $5/mo to run, and the indexer which is more complicated approx $100-150/mo.

I believe you are missing one of the important ideas topic starter is trying to deliver: Small developer teams wants to be able to bootstrap their solutions in a matter of hours/days. In most cases they neither have resources nor expertise to setup their own hardware/indexers. Moreover, they are probably at early stages of their idea and are more interested in spending their time and energy on the product, not on hardware. By requesting them to setup their own hardware for indexers (or other components) we are artificially making an entry barrier too high for some teams and missing out some potential unicorn projects.

That being said, I agree that running a full-fledge wallet (or any dAPP) using somebody else’s API is not helping with decentralization and prone to errors. But probably letting small teams to create a load of 3 req/sec could just help them to validate their idea on real customers and then decide whether to invest resources on hardware.

I strongly believe everything written above could also be expanded to other components of NEAR protocol and the idea of giving a free tier (like AWS) for using some APIs could just benefit the ecosystem in the long run.

5 Likes
9

I understand that bootstrapping phase and support from the ecosystem. There’s partners coming onboard to address these gaps. Also the projects could collectively run things and generate some income that way as you described.

It’s just a bit surprising that these projects were going to market without their own APIs and it’s kind of clear that the wallet teams were not aware of the usage.

Ultimately these are growing pains of the ecosystem. Let’s be thankful that there’s a dialogue (thanks @web3hedge) and we can figure out some ways forward together.

6 Likes
10

To the best of my knowledge (please correct me if I’m wrong), there’s currently no easy way for a user to check fungible token balances of a certain address. Almost all EVM block-explorers offer this, but sadly none on native NEAR.
This is to say that many projects have to implement token balances display for their relevant contracts in the webApp, even if they’re not a wallet/ block-explorer project. Until some block-explorer or free analytics tool implements this, it doesn’t make sense for a project to spend significant time & effort on a feature that’s irrelevant to their main mission.

3 Likes
11

If it’s irrelevant to their main mission, why do they need to display all the NFTs and token balances in the first place?

Not meaning to be rude, but if your app depends on the user’s token balances, you should have a solid infrastructure for where you’re going to get this information. Like if you’re making a wallet…? There are lots of community and third party solutions as well. Also comparing NEAR (mainnet for less than 2 years) with Ethereum (mainnet for 7+ years) is a bit apples and oranges. If you zoom out, NEAR is doing incredibly well for tooling and developers on a time x performance basis.

If you’re not building a wallet…
There’s a lot of ways to use the free RPC to check for popular tokens and NFTs, you just need to work off your own list, and there’s probably only 20-30 contracts total that would matter for most apps.

1 Like
12

Please keep in mind that we’re talking about this:

@mattlockyer you’re talking about what should happen long term, not now, in the absence of 3rd party providers. Btw, everything you said applies to RPC nodes to a greater extent. You know user intent is critical in DeFi. RPC providers can collect extra data, censor TXs, do MEV… yet, not meaning to be rude, how many of Proximity’s portfolio projects run their own RPC nodes? (P.S.: I understand that RPC services are documented + intended for public use, but that doesn’t make it less critical for DeFi apps to rely on external providers).

I agree with you on the overall vision, hopefully projects will pay for their own usage. Heck, I hope every user runs their own light stateless zk-whatever client, and indexes his own assets, but neither are applicable right now. What endpoint can I use for a user’s tokens/NFTs? Do I pay with FIAT or Crypto?
That aside, it doesn’t make sense for all projects to tackle the same problem, I’ve seen so many projects mess up their indexing (node is down, or indexing failed transfers as valid). It doesn’t make sense for them to run their own indexer infra along with monitoring, redundancy, figure out scaling… Costs aren’t just the $5, it’s also dev time and code maintenance. As you correctly pointed out, eventually a project will figure out a business model around it, until then, Imo it’s worth running as a public good to bootstrap the eco-system :pleading_face:

I didn’t mean to talk down on NEAR, I’m here because of my conviction that it’s a better platform, but I think infra help is needed here more than EVM chains EXACTLY because NEAR is still new and there are no options (yet) other than burdening every project with running their own stuff.

3 Likes
13

Yes I see your point now that it’s a shared infra problem with an easy solution… Get more infrastructure providers out there. I think many are working on it. This kind of stuff takes time.

It’s incredibly frustrating. I have worked with partners in the past when I was on DevRel and I just begged them to try running the indexer from the explorer team and they just didn’t have the bandwidth or someone with Rust expertise to set it up and maintain it. As a community sometimes were just at these speedbumps and bottlenecks.

Good thoughts in your most recent reply though. There’s easily a path to a sustainable business model for someone who runs a freemium + paid tier indexer on NEAR because right now there’s absolutely zero competition AFAIK.

5 Likes