grothoff

https://taler.net/ would be happy to get help.

It's only partially open source. Some server-side code remains proprietary, and the client-side will depend on proprietary code of Google and Apple and they do not plan to support platforms that are actually Free Software. The law overall is badly written. For example, articles 12 and 26 effectively say that "The source is shared with public, except if it is proprietary or insecure." Or take Article 4: "The government may operate systems that protect the privacy of the identity subjects."

Not quite. If you reside in Switzerland, you can own rental homes. Just foreign non-residents cannot buy.

We do need to expire cryptographic keys eventually, there is no sane alternative to this. Now, note that "regularly online" here could mean once every X years depending on how the system is configured.

GNU Taler (https://taler.net/); privacy-preserving payment system. Written in C/Java/TypeScript/Kotlin/Rust/Postgresql/etc.; needs include coding (especially integration into other applications) documentation (review, proof-reading), testing (incl. benchmark, UX), packaging, translation (Weblate/gettext); any help welcome ;-).

On this Internet if you don't trust third parties to route all of your traffic through and peers are behind NAT or CGNATs. Or imagine a mixed network with some peers on https://en.wikipedia.org/wiki/Wireless_ad_hoc_network (s), possibly with some connected to the Internet. The key assumption we have (for the random walk to work) is that it must be a small-world network (https://en.wikipedia.org/wiki/Small-world_network) and network topologies surprisingly often are.

Actually, there are two: One in C at https://git.gnunet.org/gnunet.git/tree/src/service/dht And one in Go at https://git.gnunet.org/gnunet-go.git/

I'm personally primarily busy with GNU Taler, but still in touch with the more active developers. Major work is still happening on the transport subsystem with the goal of improving NAT traversal. Some work is being done to make the code run on Android. A messenger application (incl. text and voice) works --- if your network/NAT are happy, which most of the time they are not (see my first point). There is also fun cryptographic work happening on Reclaim:ID (SSI), and improvements to the GNU Name System (registrar implementation, automatic scalable import of large DNS zones). Plus some work on automatically testing the system using Linux network namespaces. But yes, quite regular breaking changes and still too frequent breakage on the transport layer means that the active network is tiny. OTOH, until NAT traversal reliably works (incl. our self-imposed restriction to not simply assume that Google runs a TURN server/ICE environment to relay our for us), GNUnet is really only suitable for developers anyway. So normal users sadly still cannot use it. But, development is still quite active.

Yes, the random walk relates to the "NAT problem". Basically, due to NAT, peers may not succeed when trying to connect to arbitrary other peers (especially if you assume no TURN servers or other infrastructure to facilitate). The same situation may also arise in mobile ad-hoc networks, where your wireless signals simply don't get everywhere. As a result, the usual greedy routing will get stuck in a local minimal. By prefixing the greedy routing with a random walk, you basically randomize the starting position, and then end up at a random local minima. Replicate at enough local minima (O(sqrt(n)) and do enough (O(sqrt(n)) lookups and the birthday paradox will make it increasingly likely for you to succeed. Without the random walk, both the putter and the getter would greedily route always to their local minimum, and if they differ, never find each other's data.

We've been mostly working on GNU Taler (https://taler.net/), the GNU Name System (https://www.rfc-editor.org/rfc/rfc9498.html) and GNU Anastasis (https://anastasis.lu/). They all relate.

NGI funded us to work on the GNU Name System (https://www.rfc-editor.org/rfc/rfc9498.html), that includes the Go implementation, updates to the C implementation, and the specification. Plus NGI funds work on https://taler.net/. Another example for a project they funded is https://cryptpad.fr/. https://nlnet.nl/project/ has an extensive list. If you actually care about privacy on the Internet and FLOSS, I'd be surprised if you did not find some project there that you know or use.

If you are working on improving privacy on the Internet with FLOSS, you can still apply for funding at https://nlnet.nl/propose.

Indeed, I just wanted to point out that the "game changing" desire of entropyie to fully automate payments can still be done with GNU Taler. So you are right that the scammer in the default deployment won't succeed, but additionally entropyie could still totally get what entropyie wants as a feature on their own system (and conceivably make this reasonably secure, too).

Not quite. GNU Taler's reference implementation requires explicit user consent for payment. But as GNU Taler is Free Software, you are free to modify the code on your system (and share your with others) to not require an explicit confirmation if you prefer that. Or even better, to add an option to do that on some "trusted" sites which you make configurable for each user via settings. I don't know if the risk is worth the UX improvement, but a key contribution of GNU Taler is that it is a Free Software payment system where you actually have the full four freedoms. Use them!

Eh, you realize that this very work on the GNU Name System prompted IETF to create the ".alt" zone for this purpose already, minus the $200k fee? Registration is open at https://gana.gnunet.org/dot-alt/dot_alt.html

You are wrong on many details here. First of all, GNU isn't even a legal entity. The only legal entity is the FSF. Second, only some GNU packages have a copyright assignment to the FSF, not all. Some packages use a DCO, and some have way more creative solutions (see https://www.gnunet.org/static/pdf/copyright.pdf for example). Finally, not all GNU packages are necessarily GPL-x-or-later. Yes, that's generally a good default (and sometimes AGPL-or-later or LGPL-or-later are good, too), but not a strict rule.

They were clearly told what can be done (like: https://www.suerf.org/docx/f_8ec57b4b3e0f08f05b4793beef0bcd6...) and what cannot be done (like: https://taler.net/papers/euro-bearer-online-2021.pdf) but for politics the technological reality doesn't matter so much, as the decision makers don't care to actually understand the technology.

Short version: see RedHat. Long version: contact us.

Eh, we never called it decentralized. And you are right, it absolutely is not. We can disagree about whether allowing the government to see your income is ethical or not. However, we have consistently stated the facts (not decentralized, income visible, expenses non-traceable).

I appreciate your concern that income transparency enables (some) surveillance. However, are you willing to acknowledge that without it, you will have significantly more criminal activity in the system and will never be legal in most jurisdictions? And that this would force most people to effectively use account-based systems without any privacy? (Or staying with physical cash, which we also advocate for, btw.).

We have a mailinglist (taler@gnu.org), and my personal e-mail is also not difficult to find out. We can always use help. Still looking for an iOS developer, for example.

At this point, different things look plausible in different countries. Consider the possibility of a major banking technology provider offering it as a feature, in which case basically on day 1 you have 1000 banks that can choose to offer it if they believe their customers want to use Taler. Or you may have a smaller bank offer Taler as a limited experiment just to see if there is a business case, with very limited publicity. Or you may have a big bank offer it as a strategic product. Or you may have even a central bank beat everyone else and launch it as the official central bank digital currency. Personally, I'll probably sleep better if it starts small.

GNU Taler uses some libraries from GNUnet (and there is some overlap in core developers), but GNU Taler does not use the P2P (or GNS) functionality of GNUnet.

Correct. The income is merely made visible. Paying taxes is still something each merchant has to do (and calculate correctly).

This will change in the future once we have implemented P2P payments. So consider it a feature on our roadmap. See https://docs.taler.net/design-documents/013-peer-to-peer-pay...

Yes, but we still need to make it easier to setup/deploy this.

There is no public roadmap on the business side as the commercial banks we are talking to are not yet willing to have their names disclosed to the public. They're rather conservative institutions (by nature), so they want things to be checked and double-checked and ready to go before going public. Plus it is not trivial (for them) to check all of the regulatory, technical and business checkboxes. I remain hopeful that we'll get through this mess "soon", but I've been too optimistic in the past.

What I can say is that we have presented GNU Taler to over a dozen central banks already. We're trying to convince them that they must give citizens privacy and that an account-based system would give them too much power.

So while the business side is not exactly transparent, what we do technically is all out there. And it's not necessarily a bad thing to have some extra time to reduce the list of known bugs before we go live. :-)

I am the GNU Taler co-maintainer and working paper co-author. The development is community-driven. But as you see from the paper, the community is talking with central banks about deploying it. There is no contradiction.