silverpill

@rbrunner7 Nice explainer, thank you

@rafael_xmr @monero This app connects to 30 clearnet domains and all images are stored on nostr.build.

@lionroe Sounds complicated, and the biggest flaw of OpenBazaar still remains: the lack of web client. We discuss this article because it is available on the web. Lemmy and other Fediverse apps are successful because they have web clients.

Why not start with existing federated software like flohmarkt? Make it federate over Tor (maybe it already does). That would solve the hardest problem, discovery. Other features can be added later.

Vendors will host everything themselves, so there is no need for any incentive model.

@monero

@monerobull @monero @owe_addams

>their garbage tier mascot

Wait, zcash has a mascot?

@monero @rafael_xmr I know how Nostr works, I just don’t think it is better. However, if it still be around in a year or two, I might consider using Nostr relays for storing AP data. Why not, if this infrastructure already exists

@rafael_xmr @monero With AP you can have multiple admins too. Server-bound accounts is not an inherent limitation of a protocol, it just happened that popular servers like Mastodon and Lemmy are designed this way.

If you’re interested in technical details, here’s what I’m working on: https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md

@mister_monster @monero Yes, this is me. I’m choosing fediverse for several reasons 1) almost everyone I care about is here 2) I think it’s actually very important to be in contact with people who maintain infrastructure (admins) 3) ActivityPub is an open protocol which is not controlled by anyone 4) better protocol design overall

Many existing implementations suffer from the lack of data portability but I figured out how to fix that.

@treetrnk @monero I recommend building on ActivityPub instead.

You’ll be able to connect to monero.town and to everything else in Fediverse. See https://codeberg.org/grindhold/flohmarkt for example. It is a bit unfinished but people are already using it. If you’re python dev you can even fork it.

@kowalabearhugs Currently, some parts of Cuprate are licensed under AGPL-3. This means anyone using this code should keep their derivative works as open source and use the same license. The license protects the project from hostile forks and generally serves as a deterrent against privatization of public goods. Lemmy, Mastodon and many other Fediverse servers use AGPL-3 license and it is totally reasonable choice for Cuprate too.

However, when this CCS proposal was discussed some people started to push aggressively against AGPL (going as far as calling it “legal nightmare”) and the developer agreed to change the license and even agreed to re-write AGPL-licensed parts of the application if needed.

As I said, this is a mistake, and makes Monero weaker. I think Cuprate may eventually become a dominant implementation because Rust provides a better security and developer experience, and a big chunk of modern cryptographic libraries is being written in Rust (especially in zero-knowledge cryptography). But now any company can safely use Cuprate as part of their infrastructure because it has business-friendly license, create a closed-source fork and hire developers who were previously working on open-source version.

The change of license is basically a signal that corporate interests are more important than interests of ordinary users. As for examples of where this attitude leads, see any cryptocurrency project where companies or “foundations” pay developers for their work and therefore shape the product. Exceptions are rare, and Monero is one of few that relies on donations and crowdfunding.

@Rucknium

>All code produced for this CCS will be licensed under MIT.

The decision to change license from AGPL to MIT was a mistake. And what is particularly concerning, apparently a lot of people are okay with that.

Such attitude led to demise of many other communities where independence was sacrificed for “adoption” and corporate takeover was perceived as a good thing.