Activity
Mon
Wed
Fri
Sun
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
What is this?
Less
More
Mini Apps Competition
825
Free
2 contributions to Mini Apps Competition
Aug 1 •
Feature request: expose the connected wallet's balance to Mini Apps
Following up on the network request from this week — here's a second small gap, with a real bug story attached. What happened: I added a pre-flight check to Nimble so a payer sees "not enough NIM" on the approval screen instead of tapping through to the wallet only to be refused. My backend read the balance from the embedded Nimiq client… and every payment got blocked. Turns out the web client runs Pico sync: no accounts tree, so getAccount() returns balance: 0 for any address it doesn't own. A wallet holding 200k NIM reported zero — before and after subscribing the address. I ripped the feature out. Then I looked for the obvious source instead — the wallet itself. It's the connected wallet, it's the user's own account, and Nimiq Pay clearly knows the number (it's on the home screen). But window.nimiq exposes: listAccounts, sign, isConsensusEstablished, getBlockNumber, sendBasicTransaction(WithData) + staking. No balance anywhere, and nothing on window.nimiqPay either (language + device id only). The ask: nimiq.getBalance() (or balance on the accounts returned by listAccounts) for the connected accounts only — no privacy expansion, the user already granted access to that account. Why it's worth it: any Mini App handling payments wants to answer "can this user afford this?" before the wallet sheet opens. Right now the alternatives are all bad: run a full node just to read one balance, depend on a third-party RPC/explorer, or let people hit a refusal they could have been warned about. It's a UX papercut in every payment app on the platform, not just mine. Happy to test a beta build against Nimble, and to open an issue/PR if you point me at the right repo. If you've hit the same wall, a +1 below probably helps 🙂
2 likes • Aug 6
Hi @Arkadiusz Galler My first thought after reading this is that indeed getting something similar to eth_getBalance is something that makes sense to have. As you mentioned all alternatives are not so nice when it comes to the developer experience and are not the way people expect to be able to fetch an account balance. We can discuss it internally if and how we could give this shape. This means though that it should happen in a different way right now since the nimiq.getBalance is not something that is supported. I don't really know your setup and infrastructure but I think reaching out to public RPC servers is the easiest solution for now. Here are links and both support Testnet as well: https://rpc.nimiqwatch.com https://rpc-mainnet.nimiqscan.com
Jul 20 •
Buy Credits - local or server side? (Tech and Marketing doubts)
Hi team, i'm almost done with my App - Other Me, which is an Avatar creation and conversational RPG which use AI Generation. To pay for images and videos, we need to buy credits so i can pay my AI services. Payment with Nimiq Pay is working well already. My questions are in 3 areas: Safety: currently we are using Nimiq Pay local (phone side) to allow sign transactions and is all good but I want to migrate to server side for security (avoid local balance manipulation = hacking the code). For the Hackathon i think the risk is low but I want to get your feedback on it; local or server? Marketing: I will start promotion of the App this week for the competition. I will focus on Web3 Nimiq community first and then i was planning to expand it to normies. I include already 2 navigation buttons for them to learn about Nimiq and to download the Nimiq Pay App. Also provide some free credits and generations of avatars so they can test it with just an email log in. My question is if there's any restrictions to use log in with Google account email for testing the app? Pricing: For testing, i was running "credits retail price"/100 to minimize cost since i already connected to production main network, but now that i will start with the marketing for users, I was planning to put back the real prices so i don't lose money when they generate video. My question is for the hackathon, do i keep lower prices for judges and early user may be x/5 or do i put the actual price from the start since the idea is for validating the model? FYI, i already have a promo of 150% credits if paid in NIM Thanks for your help and advice. Regards, Luis
1 like • Jul 22
Hi @Luis Cajiao , Addressing your Safety concern: when there is a payment or any form of authorization involved that would give a user access to something or spend on something, I sincerely advice that there is a server component involved that verifies this spending or authorization is valid and legitimate. Without this extra validation you could run in undesired consequences causing some entity (whether it be a different user or you as a provider) to run into incorrect/malicious spendings/authorisations. To summarise: that the balance is stored in localStorage is not a problem but should be frequently be retrieved and updated from a server component to the client side . Also when it comes to making payments and giving access to content that is hidden behind a paywall, the signing of these transactions can happen client side but must always be verified by a server component. Addressing your Marketing concern: there are not restrictions when it comes integrating existing/centralised authorisation systems however the question you should ask yourself is whether this is really necessary and desired from an UX and privacy point of view. Because if your users care about privacy, or don't want to connect with a service like Google, it could be that people won't use your service. If you still want to pursue this, maybe consider it an optional element and support different kind of mechanisms. Addressing your Pricing concern: I would consider this a strategy problem. If you want to attract new users early and give them this "i'm an early adopter" kinda feeling, having a reduced price tag is the way to go. However, the downside of this obviously is that you pay for this price reduction and question is whether you can and willing to take this risk.
1-2 of 2
