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.

They're academic cryptography researchers. They do not care what messaging system you use. This is what academic messaging cryptography papers look like; a paper like this is why Matrix transitioned (is transitioning?) from ad hoc cryptography to MLS.

Thanks for clearing up that the issue is academic as in irrelevant concerning nostr

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.

Thank you very much!

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?

founder here. great question.

the way i see it, the sales side should be bespoke -- because everyone has a different product, and way of selling/configuring, and the factory-floor side should be bespoke -- because of all the different types of equipment. but the middle layer (purchasing, bill of materials, invoices, sales orders, scheduling, processes, work centers) can be standardized.

for me that's why it's important that the middle layer is open source. so that the bespoke layers can tie into it.

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

ahh, it does -- but there's a slight hair to split.

on sales, carbon supports quoting, sales orders, invoicing, configurator, etc -- but it does not attempt to create a website for you where you can list your products and their configurations. the idea is that you have a site, the site sends info to carbon through the API (whether it's a quote or an order), and then things begin from there.

similarly with production except that the shop floor is pulling intstead of pushing. carbon manages the schedule, the jobs, the capacity planning, etc. and provides a UI for guys on the shop floor to record their time and materials. but if you want to interface with a machine, you'd be pulling information out of carbon through the API, and relaying it to the machine.

Great Q&A's, thank you for taking the time to answer! Sounds like a great way to handle the complexities of business reality.

At the ERP level everything is abstracted such that every operation is just a black box - stuff (raw materials, subcomponents, labor) goes in, stuff (assemblies, finished goods, scrap) comes out.

This is too funny to be true.