fiatjaf
Joined 14 years ago
Karma
3,999
Submissions
4,457
Member since
May 31
https://njump.me/npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
View on Hacker NewsRecent submissions
Comment · 2 months ago
Try https://gitgrasp.com/ for an open protocol approach that can't be shut down and uses normal HTTP git servers.
Comment · 4 months ago
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).
Comment · 6 months ago
That one specifically fails catastrophically for me.
Comment · 6 months ago
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.
Comment · 6 months ago
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.
Comment · 8 months ago
X is bigger than ATProto and wasn't included either?
Comment · 9 months ago
Comment · 10 months ago
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.
Comment · 1 year ago
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.
Comment · 1 year ago
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.