So I'm a web developer that works mainly in Python (Flask), and I believe in Monero. I recently had an idea to make an open source P2P marketplace. Basically, this would work like Nostr (or on the Nostr protocol) where everything is decentralized, allowing each individual merchant to be responsible for their own legality. Payments wouldn't be handled by the marketplace. All that it would do is display the seller's receive address or qr code, and then check if the payment came through in full. So the seller would need to provide their receive address and view key which would be stored locally on the seller's computer. Once the payment is received, the marketplace would mark the order as confirmed and the seller would be responsible for fulfilling the order. I could even automate the release of digital goods on confirmation.

Since there is no way to really enforce that sellers are legitimate with this idea, there would need to be some kind of review system, like what LocalMonero.co has. Basically you can rate a merchant if you have bought from them before. People who cheat the system would drop in rankings and be avoided, while good sellers would move up in discoverability. And all merchants would be discoverable in the home screen via search or browsing. You could also subscribe to favorite merchants.

In my mind, this marketplace would solve a lot of problems at once. First off, it would make a decentralized place to buy and sell goods in private. This adds liquidity to Monero and gives us all a way to use our Monero for goods that we actually want to receive. Making the on boarding to this app super simple would allow it to basically function like a P2P amazon or ebay. The more people that sign up, the more things we have available. Merchants can be businesses or individuals.

Another thing it solves is onboarding to Monero in general. Instead of having people buy their Monero, they can get a wallet app on their phone, make a merchant account as quickly as you can sign up for a Nostr account, and sell something for Monero. No CEXs, just exchanging goods for digital cash. Want more Monero? Sell some more stuff? If it gained enough traction, it could easily attract more people to Monero as well.

This has even been done before, but it is on the Lightning Network and requires you to set up a lightning node, from what I can tell. It's not as easy as scanning a qr code to send money to someone for a good. Still, it's worth checking out. Here's the code: https://github.com/lnbits/nostrmarket, and here's a demonstration of it: https://www.youtube.com/live/2NueacYJovA?feature=share&t=6846

I'm posting this all here for two reasons. First, I wanted to know if this makes sense to anyone else. Does this sound like as good of an idea to others as it does to me? Is there anything I am missing? Has this been done before with Monero or is it being worked on by anyone else? I know of MoneroTalk's XMRBazaar, which was part of the inspiration for this, but from what I remember, that was going to use mediators to facilitate transactions, which is more overhead than I am thinking is necessary.

The other reason I bring it up is to see if others are interested in helping (or taking the idea and building it themselves before I can). I am inexperienced in coding around Monero as well as Nostr. I'm not afraid of the Monero part. That sounds pretty straightforward, especially with the python-monero package. The Nostr stuff might take me a while to figure out though. And since this seems like such a good idea to me, I'd rather tell others about it and maybe get a workable version sooner than keep it to myself. So if you'd like to help or run with this idea, go for it.

Thanks in advance.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 3 points 9 months ago (1 children)

You're the maintainer of mitra right?

Why fediverse over nostr? I'm a long time fediverse user and I absolutely love nostr compared to fediverse. No admins! It's actually censorship resistant and you don't have to worry about clustering of instances and being eclipsed from the network. IMO the fediverse is a mess that I used only because there was nothing better, I don't like the federated model at all and nostr is just far superior in terms of independence, censorship resistance and privacy.

[–] [email protected] 2 points 9 months ago (1 children)

@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.

[–] [email protected] 2 points 9 months ago (1 children)

I think if you gave nostr a chance you would see some benefits even for those reasons, like you also get to be in contact with the people that maintain infrastructure (relay admins), some admins can require the payment of a fee or simply whitelist your pubkey to read/write notes, which creates "closed communities", but the difference from AP is you are able to have many different relays at the same time for your infrastructure, so you don't have a "single admin" that you may or may not like or trust that much, you can pick one or many at any time, or be your own

[–] [email protected] 2 points 9 months ago (2 children)

@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

[–] [email protected] 2 points 9 months ago (1 children)

@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

[–] [email protected] 1 points 9 months ago (1 children)

I just think it is a way simpler design, everything is a variation of the NIP-01 note https://github.com/nostr-protocol/nips/blob/master/01.md#events-and-signatures

{
  "id": &lt;32-bytes lowercase hex-encoded sha256 of the serialized event data>,
  "pubkey": &lt;32-bytes lowercase hex-encoded public key of the event creator>,
  "created_at": ,
  "kind": ,
  "tags": [
    [...],
    // ...
  ],
  "content": ,
  "sig": &lt;64-bytes lowercase hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
}

So data portability is enforced by default for the protocol, and it is flexible in a way that clients can support new event kinds without knowing about it, so adding a video event kind to create a youtube alternative would show up even on outdated clients as they'll still be able to show every note events, and the same for outdated relays that will continue to store every note event you broadcast, you don't need to spawn a new server to self-host a new instance of a nostr implementation, just use the same clients and same relays as always, so people have made torrent sharing sites (https://dtan.xyz) and video platforms for example and it doesn't seem like the AP protocol is very open and flexible to these ideas and implementations

[–] [email protected] 1 points 9 months ago* (last edited 9 months ago)

So I think that because of this, ease of development, ease of use, nostr has a big chance of staying around for 2 years still and maybe even bigger than AP but I may be wrong

[–] [email protected] 1 points 9 months ago (1 children)

What would it take to have this in AP at the current state, and like could mitra and other clients start supporting these portable objects and just wait for others to catch on?

[–] [email protected] 1 points 9 months ago

@rafael_xmr @monero Support for portable objects can be added to existing Fediverse applications, the idea is relatively simple. However, implementing it might still require significant effort because of the fundamental shift from "one account -> one server" to "one account -> multiple servers". I've started to work on this in Mitra, but we're still several months away (at the very least) from anything usable.

Once this idea is proven to work, I expect rational developers to adopt it, because the benefits of data portability seem to vastly outweigh its downsides.