Hi, I’m trying to architect a flow where users can send donations to other users, and I have 2 questions for which I can’t immediately find an answer in the docs.
I find reference to a browser extension and a phone implementation for the wallet in the Taler FAQ.
Is there also a plain Node.js/Javascript implementation, which can be used in a non-browser App (like a CLI, or an Electron application)?
For a use-case where users can only donate, but do not receive anything in return, is a Merchant Backend needed, or does it suffice for the receiver to just have a wallet?
Based on: 2. User Guide — GNU Taler, I should be able to implement the following flow:
Donator sends a request to a server operated by the receiver, genre GET /donation-request?amount=5
Receiver sends a donation request back, with reason ‘Donation of 5 euros for (whichever project is being sponsored)’
Donator selects ‘pay’
Without needing a Merchant Backend. Is this correct?
I believe so but I will let someone else respond to this one, maybe you can detail a little more your use case to get a more specific answer.
In fact the issue is not technical but legal, Indeed in such a case a merchant back end will not be needed, however the process would still need to go through an exchange. And in the context of NGI Taler peer to peer implementations are not planned yet. This does not mean P2P will not be implemented soon, it will depend on the integration endeavours.
The use-case is an app where people can listen to and read other people’s creations. There is an option to donate directly to the artist, which would use Thaler. The app is distributed as an electron-app which runs natively, and as as a Single-page application which runs in the browser. If I can use an existing Node module to interact with the wallet from the electron-app, that would be ideal.
As to the second point: thanks for the explanation. It’s no problem that the process needs to go through an exchange for my use case.
If I understand correctly, the payment logic can already be implemented using Taler’s imaginary test-coin (Kudos). The integration with real money then depends on the implementation of P2P payments in NGI Taler, which is on the roadmap for some time during the next two years. This is completely fine by me.
In fact, I believe my use-case overlaps with the ‘Donation and Pledges’ use-case of NLNet itself, which plans a prototype for December 2025, and production usage in December 2026 (according to this roadmap NGI TALER Roadmap).
Your project sounds very nice! It resonates well with some current implementation projects and prospects such as:
as you mentioned from the NGI TALER roadmap, NLnet donations and pledges is scheduled and since it’s currently facing the regulatory issues @natacha is referring to, we will make our best to allow this topic to be documented and discussed here;
@howrecently mentionned Castopod, Faircamp, Funkwhale and Mirlo as softwares that could benefit from GNU Taler payments;
my own approach of the donation/tipping/crowdfunding issue, that didn’t lead to a move forward yet.
So we’ll be glad to support your project here!
Considering the technical aspect,
This server is referred in the project as the “Merchant Backend” which can be shared among multiple tenants (meaning that some kind of cooperative or music label federation could host a single one or use a pre-existing one) and
Thanks! I’ll make a separate thread properly explaining both Dcent Beats and Dcent Reads soon.
Both references (to the music platforms and to your ideas on crowdfunding etc) are interesting, I’ll keep track of those. I think quite a few use-cases boil down to donations.
I’m still not completely clear on the architecture. Why do I need a merchant backend just to send a donation? My understanding was:
I (as artist) own a wallet (but not a merchant backend)
Using the wallet API, I can create a donation invitation for someone else (2. User Guide — GNU Taler)
Someone else can parse that invitation, and send the money my way from their wallet
This transfer goes through an exchange (but not a merchant backend)
If that is true, then there’s no need for a Merchant backend for donations. Instead, the server can live on a machine in the artist’s home, and an authenticated peer-to-peer connection can be used to send the equivalent of a GET /donation-request?amount=5 request (in reality it wouldn’t use http over a publicly accessible IP, but a remote-procedure call over a P2P connection, which can connect devices across firewalls).
The reason I’d like to use this approach is because this way it remains more peer to peer: users fully control both their creations and their wallet, and it’s up to them to redistribute their income to other parties (like their label), rather than the other way around.
From a technical point of view, it also avoids the complexity of the merchant backend, since there’s no real ‘shop’ involved.
Of course you can just use P2P transfers to send money from one wallet to another. The problem might be rather legal than technical: It might not be possible to deposit large amounts from a Taler wallet back into the traditional banking system - you might need to be registered as merchant to be allowed to do that.
Hi @Marc, thanks for this answer! Now this makes me think that a circulatory economy would make GNU Taler much less regulatory constrained, right?
I mean, what if the tokens are “never” converted back in euros but rather from wallet to wallet, then no limit would apply to the possible amount of traffic?
The scenario where you tip someone (e.g. an artist you like) by publishing a TALER wallet address as said individual creator doesn’t really need much technical infrastructure, just like in the real world where you can just publish a traditional bank account number or put a hat on the pavement. ‘Integration’ is just mentioning the wallet address.
As @Marc said, the issues are more on the legal and fiscal side. Donating in the fiscal sense of the word (in Dutch: “schenken”), certainly to a registered charity, makes such donations tax deductible. Selling downloads of a song/book/etc or an online performance might require VAT. How 10 000 one euro tips are treated fiscally (in terms of income) is likely analogous to the real world, you should consult a tax advisor. TALER allows for income transparency, so one can prove that a large amount of small donations were made. However, you need to make plausible that you are not being used to launder money, or not selling regulated substances, etc.
@Ada: of course, if the money flows from TALER wallet to TALER wallet (“circular economy”) not a lot of issues should crop up. However, somewhere down the lane someone needs to buy food/pay rent/etc, and converting via the exchange is necessary. At that point, you will probably need to have a good explanation to the bank.
Crowdfunding a new album or book is yet another form of financial support for creators (in the Netherlands for instance there is https://www.voordekunst.nl) you might want to look into. However, there VAT will certainly come into play.
Thanks for the further context Marc and MichielLeenaars, that was very helpful.
I think I know enough to get started with the technical side: it boils down to supporting wallet-to-wallet transactions.
However, it is clear that there is a little bit of legal/fiscal uncertainty as well. If there is already a thread where people are discussing these aspects, feel free to point me there. If not, I’m sure it will be discussed more as integration with actual currencies comes closer.
My take-away for now: I think artists will indeed have to pay VAT on income from these donations (unless there’s some special fiscal regime for artists, but that’s not an issue related to Taler and is likely to be country specific). That’s fine, as long as it’s hassle-free for the people who donate.
Yes indeed, I’m still building on the Hypercore stack, continuing with the Dcent Reads project around P2P self-publishing, and also working on something similar for music (Dcent Beats).
The P2P donations would be the monetary part of those projects. I submitted a proposal to the NLNet Taler call to implement that.
I’ll open a separate thread soon to introduce the projects here.