Taler
in the chat
Payments from the messenger — proposed for GNU Taler
[1] This fork of the GNU Taler wallet for Android and iOS lets a messenger start and track peer-to-peer payments. The messenger and the wallet talk only through plain deep links. The messenger never touches money: amount, confirmation, coins and keys stay in the wallet. Signal is the first client that works end to end, Mattermost is the second. The goal of this page: bring the wallet side back into GNU Taler.
People settle money in the chat: who paid the pizza, the shared rent, the concert
ticket. Today they leave the chat, open the wallet, type the amount, copy a link, come back
and paste it. Here it is the + menu of the chat, an amount, one confirmation
in the wallet, and the payment arrives as a message in the same conversation.
Name and avatar of the chat, group size and disappearing-message timer go to the wallet
as display hints. The subject is prefilled (send via Signal: Damian). In a
group, the wallet splits the amount and creates one share per member in a single step.
The payment message shows amount, exchange, status ("waiting for Damian", "accepted") and how long it stays valid. The messenger reads these values from the exchange, not from the message text, which the sender controls. The wallet shows the messenger, avatar and chat next to each transaction; one tap jumps back to the message.
No account linking, no payment provider inside the messenger, no app-to-app IPC.
The wallet answers only messengers on a hard-coded allowlist (scheme, package, signing
certificate). Works with every exchange the wallet already knows. A messenger without the
integration still shows a clickable https://wallet.taler.net/link#… link
(DD 103).
- opens the wallet with a link
- carries the payment link as a message
- shows amount and status
- never confirms, never holds keys
⇄
<scheme>://taler-return
- creates, accepts, refunds, cancels
- the user confirms every payment here
- holds coins and keys
- checks who it returns to
(unchanged)
- as today
- the messenger reads only public endpoints: contract and purse status
All legal and regulatory questions stay where they are today: with GNU Taler and the operator of the exchange. Signal or Mattermost play the same part as e-mail does for a payment link: they carry it. No code path in the messenger confirms a payment, and the messenger cannot create, accept or cancel one without the user confirming it in the wallet.
Signal
- fork "Signal für GNU": send, request, group split, accept, refund, cancel
Mattermost
- fork "Talermost": same protocol, own return scheme
talermost://taler-return
Element X and others
- no change to the wallet beyond one allowlist entry
- Register a return scheme, e.g.
mymessenger://taler-return. - Open
talerlink://compose-send?…&returnUri=…from a chat. - Read the return link and send the payment URIs as a message.
- Show the status by asking the exchange, never by trusting the text.
The wallet side needs one entry in AllowedCallers
(scheme → package + signing certificate). On the upstream-ready branch the only default
entry is the official Signal app (sgnl, certificates as published by Signal).
The protocol is written down on Sheet 2; anyone may implement it.
- Messenger interface
talerlink://.compose-send,compose-refund,compose-abortand the accept/cancel action links forpay-push/pay-pull. Separate scheme, so web pages cannot trigger it (Android: own intent filter withoutBROWSABLE). - Confirmation screens. Send or request with a direction toggle, recipient name and
avatar, prefilled subject. Refund a received payment, with a warning if it was already
refunded. Cancel own open payments in bulk, only after the user confirms; a URI this wallet
did not create is answered with
not_own. - Group split. One purse per member, created in parallel with retry and polling. The total of all shares is checked against the balance before the first purse is created. The shares appear as one collapsible row with a paid / open / declined bar.
- Verified return. Exactly one return per operation to
<scheme>://taler-return, query always rebuilt. Android checks package and signing certificate against the allowlist and sends an explicit intent; if the target is unknown, the result is copied instead. - Structured payment data. Amount, subject, state and all URIs go back as JSON
(
talerPaymentData) instead of free text. The messenger can preview an incoming payment link. - https payment links (DD 103). Wrap and unwrap
https://wallet.taler.net/link#…, findtaler://URIs in pasted text, and show a summary when several shares are pasted at once. - Messenger contact on each transaction. Messenger logo, avatar and chat name in the
list and the details. A tap opens the chat at the payment message
(Android
taler-return?open=, iOStaler-open?uriHash=). Android takes logo and name from the system, only for a verified package. - Time and validity. Below each peer payment: when it was sent and how long it stays valid, in the warning colour during the last 5 % of its lifetime.
- Bearer tokens stay private. Own payment URIs are stored only as SHA-256 hashes, never logged, never put into implicit intents.
| Android | 18 commits · 81 files · +9,065 / −241 lines, on top of upstream master |
| iOS | 16 commits · 47 files · +7,159 / −53 lines, everything behind #if TALER_SIGNAL |
| Order | commits go from URI parsing and DD 103 links over the link interface to compose screens, group split and contact line, so they can be reviewed one by one |
| Rebased | regularly onto upstream; iOS on 1.6.17 |
| Dependencies | no new libraries. Android declares kotlinx-serialization-json (already used upstream via taler-kotlin-android) directly and enables kotlin-parcelize |
| License | GPLv3, like upstream |
The messenger side lives in separate forks and is not proposed to GNU Taler:
the + menu entry, the payment message, status polling against the exchange
(every 60 s, and right away when the wallet opens the chat), local contract decryption, accept, refund
and "delete for everyone" that cancels open payments.
Also not proposed: the personal build settings of the test apps (package names, update server, signing keys). They live on a private branch.
+ menu has a new entry: Send with Taler.
send via Signal: Damian, expiry. The user confirms in the wallet.
"Talermost" is a fork of the Mattermost mobile app for Android. It uses the same links as
Signal and its own return target talermost://taler-return. The wallet treats it
like Signal: one more allowlist entry with its package and signing certificate. Direct
messages pass the partner's profile picture to the wallet; channels and groups go without a
picture. This is the proof that the protocol is not tied to Signal.
| Messengers | Only Signal and Mattermost. How other messengers behave, or whether the protocol has to adapt to them, is open. |
| Devices | One iPhone 12 mini and one Fairphone 6. On both, Signal für GNU ran as a linked (secondary) device of a private account. It can also run as the primary device; only next to the official Signal app is the linked mode needed. |
| Servers | The official Signal server infrastructure was used as it is. No load or stress tests were run. Please do not run any against it. |
| Receiving | Receiving Taler payment links has only been tested lightly. |
| Exchange | All tests ran against exchange.demo.taler.net with KUDOS. |
Known open point from the protocol: the wallet commits a payment before it returns to the messenger. If the messenger lost its short-lived operation entry in between (process killed, more than 15 minutes), the payment exists in the wallet without a chat message.
github.com/Baum1999/taler-signal-integration
Fork of git.taler.net/taler-android.git.
Branch master holds only the integration on top of upstream master.
New code in net.taler.wallet.link.
github.com/Baum1999/taler-ios-signal-integration
Fork of git.taler.net/taler-ios.git.
Branch master, all changes behind the compile flag TALER_SIGNAL
(enabled for the GNU_Taler target).