Nostr needs a Monero Takeover

In my view, Monero is only one piece of the equation to digital freedom. You need the rest of the “encryption as identity” tech stack:

Monero is to Money, What Session is to Telegram, And Nostr is to Twitter.

Censorship on Twitter has given rise to this decentralized micro-blogging alternative that uses encryption as identity for unstoppable free speech.

I narrated this brand new animated video which goes over how Nostr works and why it matters: video.simplifiedprivacy.com/nostr/

Nostr is right now dominated by Bitcoin Maxis, we’re organizing a Monero takeover. DM us on Nostr: npub14slk4lshtylkrqg9z0dvng09gn58h88frvnax7uga3v0h25szj4qzjt5d6

moneromaxi,

It’s made for BTC maxis by BTC maxis and it doesn’t support Tor decently in any clients. What does this mean to me? Fuck nostr

ShadowRebel,

Monero would be hurt by being on Nostr, as ring signatures rely on it being unknown who sent to who. Once it’s in the public who sent many transactions, it would rule out certain ones from being part of ring signatures. When you say fuck Nostr, you’re really saying fuck free speech.

gunnm,

Nostr users are going to hate more Monero if they try to take over, so why not fork it and make it compatible with the current Nostr?

ShadowRebel,

Monero would be hurt by being on Nostr, as ring signatures rely on it being unknown who sent to who. Once it’s in the public who sent many transactions, it would rule out certain ones from being part of ring signatures.

trymeout,

I wish session remade their client with flutter and made it feature rich like Element/Jami/SimpleX.

I like how sessions handles users IDs as seed phrases and also wishes sessions will allow you to manage multiple user IDs from a single seed phrase.

Nostr FTW!

ShadowRebel,

I agree with you that their current system of TypeScript should be changed. They are releasing a client that will have multiple identities at the same time. But you can actually do this now on Linux (without a VM) by creating multiple desktop entries linked to different underlying software. However I agree that most won’t wish to follow a guide taking an hour on how to do this

comcreator,

We need more monero devs to develop monero relay payment integration on nostr. Lightning payments on nostr can remain for all I care but lightning is not the answer.

Same goes for integrating other relay paymemt options like Haven protocol, BCH and LTC.

I like to see others, not just crypto people but more people of all kinds flock to nostr.

k4r4b3y,

@ShadowRebel nostr might be cool and I do wish it would have more Monero people in there; but, mitra.social is already doing good things. It is ActivityPub compatible (thus federateable), it has baked-in Monero tips and subscriptions support, and it can work over tor + clearnet. Quite good for Monero people to be in.

SoulReaver,

Can you send me a mitra.social invitation?

k4r4b3y,

@SoulReaver I am not the admin of the mitra.social network. You should ask @silverpill for that.

However, I would advise you to host your own mitra instance. It is quite easy to setup.

SoulReaver,

Yea I contacted silver and silver gave me a key, thnx.

k4r4b3y,

@ShadowRebel in fact, I am posting these comments from my own mitra instance. It can play-nice with the lemmy instance of monero.town, since they all share the same ActivityPub protocol underneath.

No need for a newfangled protocol that tries to re-invent the wheel.

ShadowRebel,

Hey man I will check out Mitra and make an account on there. Thanks so much, I’d be happy to be part of your community.

This being said, Monero has unique issues in that the possibility of sanctions such as Tornado cash would force us to abandon IP address and DNS based systems such as federated ones. I like the approach that Mitra takes with a sign in, and will look further

k4r4b3y,

@ShadowRebel

>would force us to abandon IP address and DNS based systems such as federated ones.

Hey I hate the DNS like the next hacker. I think we can migrate to Tor HiddenServices and use Onion URLs for our mitra instances---if the need be. Afaik, mitra allows tor-only instances (they can federate to other onion instances, and/or to the clearnet ones over the tor exit nodes).

Definitely checkout mitra.social.

cc: @silverpill

Saki,

While I’ve been a huge fan of Tor for like 10+ years, the Tor network relies on a relatively small number of “centralized” node operators. In the long run, I2P might be a better option, though not yet sure…

k4r4b3y,

@Saki I like I2P. I use it for my torrenting activities, it is great---no need for VPNs for torrenting anymore.

However, Tor has its own advantages, being more reachable by a greater number of people who might not be as tech savvy as us, is one of them. Like it or not, Tor's abundant exit nodes is one other advantage that it has over I2P. In the case of something like mitra.social microblogging service, if one hosts a onion-only instance of it, Tor allows him to federate with clearnet peers over the exit nodes, and thus allow the onion-only instances of mitra/pleroma to be also in connect with the greater fediverse.

>the Tor network relies on a relatively small number of “centralized” node operators.

Any sources that makes you say that?

silverpill,
@silverpill@mitra.social avatar

@k4r4b3y You can configure your instance to talk to I2P instances.

federation.i2p_proxy_url in config

Tor and I2P are not mutually exclusive.

k4r4b3y,

@silverpill Maybe I should do that. Is there any poasters from I2P mitra/pleroma/fedi-sphere?

silverpill,
@silverpill@mitra.social avatar

@k4r4b3y

ping @iwojima @iwojima

k4r4b3y,

@silverpill Currenlty my mitra server doesn't support I2P. If he posts something under your mention, am I going to be able to see it?

silverpill,
@silverpill@mitra.social avatar

@k4r4b3y No. Your server can receive the message but it can't figure out who sent it because the sender is an i2p host.

Saki, (edited )

Yes, currently Tor is much more convenient, no argument there :)

The # of exit nodes is relatively so small and the list is public, anyone that wants to block Tor traffic can do so easily. Plus, for good or for bad, I think the Tor project is US centerd, funded by various American governmental agencies. Bridges, snowflake… they’re more like P2P, but snowflake works via a monopolistic “broker“ that is Google (of all things…?). So in theory, it may be relatively easy to shut down snowflake or selectively block communications via Tor in general.

That said, if we do use hidden services, then exit nodes are irrelevant and everything may be fine (hopefully). I2P is relatively new; Tor vs. I2P is yet inconclusive—probably both have their own forte. I’d like to experiment (play with) both to get better intuition/understanding. Thanks for you insightful comments.

k4r4b3y,

@Saki

>Tor network relies on a relatively small number of “centralized” node operators.

Here's a recent talk that argues to the contrary: https://media.ccc.de/v/camp2023-57172-a_guided_tour_through_tor_network_health_and_performance

Saki,

Thanks for your comment & link. I too think currently the Tor network is much bigger. I like Tor too! At the same time, recently I have this vague feeling that i2p might be the future… Honestly not yet sure.

silverpill,
@silverpill@mitra.social avatar

@k4r4b3y @ShadowRebel Yes, self-hosted Tor instance is a way to go if you want to be completely independent. People who don't self-host can link their account to a public key and move to another instance if something bad happens, this is also supported (still experimental and undocumented though; I'll try to find some time to write an explainer).

Finally, the protocol can be extended to support nostr-like architecture with simple relays and rich clients. Maybe I will implement that too, or somebody else can start such project.

mister_monster,

I’m sorry dude, but I have to tell you, Monero people overtaking Bitcoin people on Nostr is just not going to happen. Nostr is maintained by a bitcoin core contributor. Most clients have lightning network integrated, as does the protocol. You’re just not going to try to overtake Nostr without creating a whole separate network of clients and relays and a different protocol specification to remove the LN and potentially integrate Monero.

Now, there are a lot of shortcomings in Nostr. The core protocol design is solid. But the design philosophy of “add what the community wants as needed, move fast damn the outcome” is a bad approach IMO. A well thought out set of design principles (while being use case agnostic) is what’s needed IMO. If I were a part of your organizing, I’d agitate to create a different protocol spec, and I have a rough idea of how such a protocol would look. It would look a lot like Nostr, it would have encrypted messaging as a first class citizen so that even relays couldn’t read your messages, and it would not have so many different message types (basically one for recipients and one for relays). All the extra stuff like verification and LN would just not be there and be left to the use case specific client design.

ShadowRebel,

Hey I had a different person tell me that the lightning is not directly integrated with protocol. The lightning payments are custodial. So when I use it on a web browser, I use Flamingo for signing nostr posts, and then Alby wallet for signing bitcoin zaps. So if it can be using separate software like that, I see no reason that other cryptos can’t be added on the client side.

The bigger issue is that having public Monero transactions would take away from Ring CT.

mister_monster,

github.com/nostr-protocol/nips/blob/master/57.md

So, most of the NIPs are optional. Technically this is a specification for an optional part of the protocol. Because of the network architecture, basically all NIPs are implemented in clients. So in a sense the person who told you that is right.

But that’s a double edged sword; because most of them are implemented in clients, building a client with different functionality means creating a different network of users. If you’re using a client without zaps and someone sends you a zap you will never know, if you send someone Monero on this client and they’re not using the same client they’ll never know. github.com/jesterui/jesterui is an example of a client for playing chess over Nostr, as an example. The people using this client are not the same people talking to each other using Flamingo, and the two groups of people cannot interact without using a different client. This is just a fact of life when you have an application agnostic network. To create a monero focused client is to create a separate Monero focused network. May as well try to make a better protocol specification.

Sending Monero via Nostr (or something like it) wouldn’t necessarily deanonymize transactions, if the protocol for sending them was designed properly. You can’t do things like derive addresses from npubs or the nostr private key, or publish transaction key images. A client could have Monero integrated and have a watch only function that notified the recipient, but nobody else could see it. This way of doing it would not give it the hype that zaps have gotten, because zaps are public, but it would work.

To see just how convoluted the protocol is check this out github.com/nostr-protocol/nips/blob/…/README.md

If you decide on the new spec route, I don’t mind helping with the spec, I already have done some rough work on the idea and have a bit of an idea what a good spec would look like.

ShadowRebel,

sure reach out via any of the methods on SimplifiedPrivacy.com , we’d love to hear from you session, xmpp, nostr, whatever you want

LobYonder,

I already have done some rough work on the idea and have a bit of an idea what a good spec would look like.

Can you expand on that? Is the idea being actively discussed/developed anywhere?

mister_monster,

No, only in my head lol. I did some rough speccing on it when nostr was very new because I didn’t like how the spec for the messages was made, it makes it impossible to encrypt without a bunch of metadata.

k4r4b3y,

@ShadowRebel @mister_monster

>The lightning payments are custodial.

Imagine my shock.

crab,

Interesting video. One question from someone who knows nothing about Nostr: If Mastodon “banning” is a problem, how does Nostr prevent csam etc? Do you only see content from people you explicitly sub to?

mister_monster, (edited )

Well, yes, discoverability is a problem on Nostr. There is a firehose feed you can get from all the relays you’re subscribed to, but that is mostly useless, as it is on Mastodon/Fedi, or really anything with a chronological firehose feed.

As far as banning, a relay can ban messages signed with your key. They can check messages and see what’s in them, so they can remove messages that violate their terms. But you’re not limited to one relay, unlike Fedi where you have an account on a server. You can broadcast your messages to as many relays as you like, and people can check multiple relays for your messages.

ShadowRebel,

Yeah mister monster hit the point on the head with the not tying identity to a single server admin

tusker,

Mastodon already replaced twitter, it has much more users than nostr, what is the point?

RTRedreovic,

Is variety in Alternatives a problem to you?

tusker,

not at all, just do not understand what nostr does that mastodon does not

it is like promoting zcash or epic cash, pointless

ShadowRebel,

The video covers why Nostr is better than Mastedon. Mastedon makes you reliant on a federated admin who can ban you. And federation relies upon DNS and IP addresses for identity, as opposed to encryption as identity.

tusker,

Overkill IMO, if you join a freedom oriented instance you will be fine unless you are a real ass. You can also run your own instance.

Fedi is the way to go as everyone can talk to each other. They already bridge over in some capacity anyway.

Rather not be tied to some BTC maxi protocol, next thing you know they will limit the number of users to 100 and cap post size to 10KB.

k4r4b3y,

@tusker @ShadowRebel

>some BTC maxi protocol, next thing you know they will limit the number of users to 100 and cap post size to 10KB.

lol'd

chicken,

do not understand what nostr does that mastodon does not

It has a really nice ethos for the coding side of it and is very easy to make stuff for. The only mandatory thing to implement is extremely short, and all of the documentation is in a single github that takes contributions from basically anyone for additions. It can very plausibly be used for stuff that isn’t like Twitter. Having cryptographic keys instead of accounts is a good concept, so are relays, makes it so there isn’t any given server that has a lot of power over you as a user. If you’re not a developer and don’t care about that stuff then yeah it doesn’t really have much mastodon doesn’t right now but it’s still cool imo.

tusker,

Thanks for the info, has potential I suppose.

mister_monster,

OK…

Nostr is a (mostly) use case agnostic transport protocol. It consists of relays, which only relay messages, and user clients, which only sign messages and send them to relays. Clients can send to as many relays as they like, ensuring censorship resistance, and users don’t have usernames and accounts and all that, only keypairs.

Now, lots of people have built on top of it ways to “verify” with servers, the maintainer has built into the protocol special types of messages that are things like account descriptions and avatars, and most of the development is focused on microblogging. But that’s not all it can do.

It’s as pointless as monero is in the face of bitcoin: it isn’t pointless. It’s a very good idea actually. I think the protocol has become too convoluted, but it does what we need it to do. It is censorship resistant, potentially anonymous publishing on the clearnet.

ShadowRebel,

Thanks for your reply. This is good stuff

gunnm,

I disagree it replaced it, people still use X.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • monero@monero.town
  • DreamBathrooms
  • InstantRegret
  • ethstaker
  • magazineikmin
  • GTA5RPClips
  • rosin
  • modclub
  • Youngstown
  • ngwrru68w68
  • slotface
  • osvaldo12
  • kavyap
  • mdbf
  • thenastyranch
  • JUstTest
  • everett
  • cubers
  • cisconetworking
  • normalnudes
  • Durango
  • anitta
  • khanakhh
  • tacticalgear
  • tester
  • provamag3
  • megavids
  • Leos
  • lostlight
  • All magazines
    •