fiatjaf

Try https://gitgrasp.com/ for an open protocol approach that can't be shut down and uses normal HTTP git servers.

Apparently you haven't fired Cloudflare, since this website forces me to go through a captcha in order to read (and I'm not even using a VPN or Tor).

That one specifically fails catastrophically for me.

A federation of forges makes no sense if everything gets centralized again in the hands of the people operating Tangled (sure, someone else could run an alternative AppView, but then if you are only on the alternative you are invisible to anyone who is only on Tangled).

https://gitgrasp.com/ fixes this.

Sorry, but this analogy is very misleading, no one browses websites through Google's servers.

For example, right now in my URL bar I read "news.ycombinator.com", not "google.com/profile/news.ycombinator.com".

If Google goes down now I can keep browsing this website and all the other websites I have in all my other tabs as if nothing had happened.

X is bigger than ATProto and wasn't included either?

See https://how-nostr-works.pages.dev/#/pathological

It's quite simple:

- You publish to, say, 3 relays.

- I follow you or want to browse your content for any reason.

- I connect to your 3 relays and fetch your content.

If I want to follow someone else and they publish to other relays I fetch their posts from those relays.

If some of your relays start censoring you you can move to other relays, or run your own, and I'll start fetching your content from those.

There's an interactive animation demo at https://how-nostr-works.pages.dev/#/outbox that explains it.

Unfortunately this paper doesn't live up to its goal of being a cheap attack on Nostr.

The fact is that clients do verify signatures from events received from servers, that is in the protocol specification and should be obvious to anyone mildly honest.

The entire assumption of the paper is that clients don't do that and it is void. Yes, they did find a couple of clients 2 years ago that didn't verify signatures -- so much for a vulnerability in the protocol. I guess they wanted Nostr to have a code police arresting client developers who didn't finish their implementation?

Aside from that the attacks they demonstrated depend on a bunch of other absurd circumstances (like you have to manually and voluntarily type the URL of the attacker server in order to be attacked) but it's not even worth talking about them since the basic assumption is so completely false already.

The encrypted messages stuff is not even a core part of Nostr anyway, Nostr is a broadcasting protocol for public or semi-public content. Encryption can be added on top and there are multiple ways and proposals for how to do it, including an implementation of MLS and other methods and I personally mostly do not care about any.

I wish the paper authors were more honest and republished their work with the title: "the dangers of trusting a cryptographic signature without verifying it", but I imagine that it would have been too obvious and worthless if it was phrased like that.

There is no blockchain, only basic cryptographic signatures on each message. And users are not tied to any servers, they can read from multiple or write to multiple. They can (locally) aggregate data from many servers or connect to a specific server, same for publishing, it's very flexible and different clients choose to do it in different ways and expose different interfaces to users.

Yes, that makes sense and that can be used later by relays and clients in order to decide whether to store or display notes from identities. In fact that's a pretty good idea.

You only read from the relays you want, relays have all the tools in the world to reject spam, therefore the solution is just to have clients that help the user enforce selecting only what they deem as "safe" relays in order to read replies from.

This is cool but P2P doesn't work. Iroh also relies on "relays" in a sense. Nostr makes that explicit and gives relays identities so they can freely enact policies instead of having to hack that in weird ways.

That's a misconception: you don't "use" relays (in the sense that you don't have to have a static list of relays you always use), you write to relays. When reading you connect to the relays of whatever the people you want to read from.

Some apps indeed use this method of selecting a static set of relays, and if that was the protocol you would be correct about centralization or bloat, but this is legacy from a naïve unfinished early implementation, most apps do the correct thing now and the rest is transitioning.

An easy-to-setup OpenWrt-based plugin to sell internet for satoshis: https://tollgate.me/

Thank you very much!

I see, I was under the impression that Carbon encompassed sales and factory floor too. Now it makes more sense. Thanks!

A stupid question from a layman: is it really how people do it?

I would have thought "manufacturing" was too generic and that you would need different software for each industry and so on.

But instead it looks like it doesn't matter if you're making shoes or cars or umbrellas or computer chips, everything uses the same software?

This is too funny to be true.

ahahah, I've said the same thing about how I used AI recently. The "hate fuel" part is really true.

You have demonstrated you have no idea of what Drivechain is, you probably never spent the time to learn how it works, and yet you feel entitled to call it "idiotic".

I get it, it's fine to not want to learn things, but that comes with the burden of not being allowed to comment on it.

Apparently you have not carefully read my criticism of the big block proposal above. I've included some numbers. A proper response would have to address those. But thank you for trying.

This big block propaganda piece fails to address the most obvious issue with their proposal: that increasing block sizes will just increase fees linearly. No one will pay more in fees per transaction because there will be a lot of space left in blocks, so people will keep paying $0.20 per transaction, which today gets us $400, so now we'll get $800? That if increasing the block size doesn't reduce the base $0.20 to some smaller average.

The actual solution to the security budget is to make a ton of payments in a (blindly) merge-mined sidechain and ensure those transactions there pay lower fees but those lower fees get aggregated into a single high-fee paid on Bitcoin. That is the Drivechain proposal: https://drivechain.xyz/.