some-username

Why I find it kind of cute is that those buys (GNS fcfs) are basically meaningless - in a p2p system everyone can just host a service like this.

I find it kind of cute that they set up this mock-up currency 'kudos' to toy around with it. (https://demo.taler.net/en/)

What makes it (more) cute is that you can use it to reserve entries in their GNS first-come-first-served service. (https://fcfs.gnunet.org/)

GNS being the GNU Name System which is a decentralized/p2p equivalent to DNS. (https://www.gnunet.org/en/gns.html)

Won't the vendors just design their prices in a way that it's economically feasible for them - they just include the transaction costs in the price?

...and, as quoted by sunshine_reggae, lower transaction costs.

My understanding here is that the main objective is to break up the MasterCard/Visa duopoly. I guess breaking up duopolies is always a win for the general public, no?

People should know that

1. it's not based on any kind of blockchain,

2. it's not a currency, it's a payment system which you could use to transfer other currencies (euro, dollar, ...) and

3. unlike most blockchain-based currencies it offers anonymity (only for buyers, not for sellers, though)

You might want to have a look at the GNS (GNU Name System): https://www.gnunet.org/en/gns.html https://datatracker.ietf.org/doc/id/draft-schanzen-gns-01.ht... To my understanding, this enables what you are looking for.

There has been a rust-library for signal in the works. I read some discussion on it that made it clear the aim was to develop a proper signal-desktop application. The rust-library has a cli, which is not quite finished. https://github.com/whisperfish/presage

I was not surprised that it happens, but I was quite astonished about the extent of it.

Also it's nice to have proof and insight.

You might want to have a look at presage - an implementation in rust: https://github.com/whisperfish/presage

You can find the main changes over the last version in the first chapter of the specification: https://bugs.otr.im/otrv4/otrv4/-/blob/master/otrv4.md#main-...

Quote:

- Security level raised to 224 bits and based on Elliptic Curve Cryptography (ECC).

- Additional protection against transcript decryption in the case of ECC compromise.

- Support of conversations where one party is offline.

- Updated cryptographic primitives and protocols:

   - Deniable authenticated key exchanges (DAKE) using "DAKE with Zero Knowledge" (DAKEZ) and "Extended Zero-knowledge Diffie-Hellman" (XZDH) [1]. DAKEZ corresponds to conversations when both parties are online (interactive) and XZDH to conversations when one of the parties is offline (non-interactive).

   - Key management using the Double Ratchet Algorithm [2].

   - Upgraded SHA-1 and SHA-2 to SHAKE-256.

   - Switched from AES to ChaCha20 [3]. The RFC 7539 variant is used [16] .

 - Support of an out-of-order network model.

 - Support of different modes in which this specification can be implemented.

 - Explicit instructions for producing forged transcripts using the same functions used to conduct honest conversations.

Yes, sure. But that's fine - everyone who wants to have their GNS can design their own DHT. It's still outside of the spec. (Which makes a lot of sense to me.)

Also from Ursula K. Le Guin: The Dispossessed.

Not mind bending for someone who spent some time trying to imagine a anarchist society (but still quite enriching), but maybe for others.

About the same time that "Microsoft plots the end of Visual Basic" (https://news.ycombinator.com/item?id=22570684).

Don't you think that "ideological reasons" can be quite a good reason to do things?

Besides, following ideological reasons only means to value certain (other) aspects higher for evaluating the question how good something is.

Usually the term ideological implies (in my book) that a person is considering the greater good, and willing to take a step back in own convenience. That sounds like a nice person to me. Maybe you could spare some curiosity for their reasons?

If you're interested in contributing: https://gnunet.org/en/engage.html

Tutorials:

Install: https://gnunet.org/en/install.html

In a Nutshell usage (wip): https://gnunet.org/en/use.html

"Physical impossibilities of p2p models" - Although there might be structural limitations, I think they're not too strong. Just because we currently do not have a major p2p network doesn't mean that it's not possible. I think it's very possible to have something like this (even for availability). You just need to have a good design/mechanism.

But there's the problem (why we didn't see something like this yet): No one puts many resources into the design of p2p-stuff. The competing, central solutions get tons of resources from big companies that try to make money with it. There is no company that tries to build something p2p because with giving away the control, they give away the possibility to make money out of it.

A working example of offline storage would be bitmessage (although I think It won't scale). A much more interesting development would be lake: https://media.ccc.de/v/34c3-8974-practical_mix_network_desig...

Let it run on the router or NAS...

Yes, cryptocurrencies was one way. (I don't think that it's really complicated.)

But on the other hand I don't think that it's really expensive. As in have a RasPi lying around at home that's keeping track of everything when you're not online. That should totally suffice for your own needs. If you have bigger needs or want to support the network (maybe even for a small compensation in whatever form) that's easily scaleable. Or think of bittorrent: It's incentivised that you run contribute back what you received. That works totally without compensation in cryptocurrencies.

About the simplification I'm not sure either. Have you tried running Gmail lately? (Not as client but as service ^^ I think that it's not quite straight-forward.) Once you have a proper working p2p network/algorithm/protocol I can imagine that it's easier to run for all parties.

The content could live at peers that are online all the time. This could be either your own node or not. If it's not your own node the network has to be designed in a way that the online node does not learn a bit about what it is storing. An example of this would be lake: https://media.ccc.de/v/34c3-8974-practical_mix_network_desig... It's also mentioned on those slides: https://grothoff.org/christian/snt2017.pdf

I fully agree. The problem is that it's even harder to design something that is fully p2p than something federated. (One thing that tries to be exactly what you want would be https://secushare.org/ But its in a very very early stage, right now. There exist others, though.) And you have to agree that (even if most people choose the biggest provider) simply having the choice of different providers or even being your own provider is a huge improvement.

If you're no big company, it's quite hard to build a device that is somewhat free, has current hardware specs and is cheap. There's a small company that is trying to continue the openmoko phones: GolDelico (http://goldelico.de/) They're also involved in the Pyra and the Neo900. They are quite in need of support. ;)