Replies (26)
Consider me intrigued 🤔
ok wait— pulled up that PR and the protocol work is legit. you diving in to contribute or just scoping it out?
Think of NIP-A5 Scrolls like this:
A normal Nostr event is like a letter.
A scroll is like a tiny magical instruction scroll inside the network:
• it tells the client what the mini-app is called,
• what inputs it needs,
• and it contains a tiny packaged program.
When you open it, your Nostr client becomes the wizard’s desk:
• it reads the scroll,
• runs the tiny program in a safe little box,
• gives it only the tools it is allowed to use,
• and shows you the result.
So instead of only sending content over Nostr, you can send behavior.
This is Javascript all over again: I can run malware, spyware, viruses, mine Monero... Except I don't even you to connect to my website: all I need is a trending note... Why?? 🤔
After my recent discovery of Flutter, I started thinking exactly the same thing.
The only sticking point is that developers using WASM have too much control over the user interface, with no safety net, and this could lead to problematic UX.
I don't think so, WASM Modules is isolated, they can't access DOM and local resources, it's memory isolated and "secure by design". Run it in a Web Worker, and it's even more isolated. Mining Monero wouldn't work well either, since it has no network access.
This NIP seems to leave a lot of the control up to the client, with only one render specific method
What is nostrscript? Isn't this nostrscript?
So you were thinking about something like this? How was the idea in your mind? What do you think it's missing in my proposal?
I kinda wanted to have more weirder render methods, or perhaps more interactivity, but I can't figure out what or why. Maybe we can add more later.
Why is the wasm embedded in the note?
Won't it be more efficient to store it in a blossom server?
That way you can have the same wasm run with different parameters.
I understand your point, but this is not adversarial thinking.
What I see is that it's opening the door for me to run arbitrary code on juicy target (bitcoiners/developers) machines. I also have an amazing delivery vector — no need to click on a .exe, no need to open a attachment, just a client opening an event in the background.
Now, I just need to find a way to break that compartimentation, and I'm pretty sure the API, if not some implementation bug, is going to give me just that... ;)
(And to be honnest, I didn't dig into it in details so I might be wrong; I'm sharing first impressions after a quick read, but I can already see the opportunity there!)
I share fully the concerns! I'm never going to allow third-party widgets to run on Nostria, that's such a massive attack-surface.
If you can break out of a WASM VM that will be because of some nasty buffer overflow bug or similar bug and you have the same chances of finding that kind of stuff in any HTML renderer, JPEG renderer, audio codec, iframe, script loader, I don't know, any aspect of a browser or other non-browser libraries. There are hundreds of possibilities.
Much easier than that is getting your malicious code in some npm module and injects itself in other people's softwares and builds; or getting an LLM prompt-injected to emit instructions with your bug in them; or something like that.
We're already living in a sea of possible attack avenues, WASM isn't necessarily worse just because it can run virtual instructions. Also these scrolls are supposed to be very small and simple, and WASM code can be read, so an evil attack can be spotted relatively easily.
Finally, it's not like you're executing automatically anything that comes through your client (like npm does, for example), you still have to check where it came from and click. In any case, either the code comes from someone you know or with a reputation or if it's a viral thing from an unknown person at least it will have been inspected by someone else, or you can ask an LLM to inspect it for you.
I've found a note from beginning of 2024 in which I was trying to come up with ideas for Nostr mini apps that would be written in WASM and shared as events. The idea at the time was to have something that fetched events and rendered tables with clickable buttons.
These were the examples I listed at the time:
- recover old contacts deleted by mistake
- cleanup inactive follows
- suggested people (based on lists of people you follow)
- event deleter
Turns out that, thinking about it now, the single "display()" function is pretty reasonable. All these functionalities can be done by just fetching the correct events (kind:0s for displaying profiles, I guess), then expecting the client to have its own delete button, follow button, unfollow button, that's it.
The same WASM can run with different parameters regardless of where it is hosted.
But whether to put it in the event body or on blossom I don't know what is best.
I think having it on the note is good because it acts as a natural size limiter and is slightly simpler to implement, reduces errors, makes it easier to reason about, reduces the number of errors and moving pieces and dependencies.
But I can also see the other side of the argument. It's a fine line to thread. For example: why wouldn't this note's content be put in a blossom server and the event be just a hash to it?
With all due respect, if pointing out at other, unrelated attack vectors is a valid answer then let's all drop all form of security consideration altogether.
The alternative is of course to give it a serious thought through adversarial thinking and poking at the holes... As I already stated it's not just buffer overflows: for example your API sends request and it's really great to send messages back to home such as e.g. a hash of a block. Way different from exploiting a codec.
Generally speaking, the idea that WASM is fully isolated is incorrect because in order to be useful you give it access to interfaces that are not necessarily well secured. As soon as you give it an API, and maybe memory chunks that could be interpreted on the other side, it opens interesting opportunities... Especially as abritrary execution is already available free!
Agreed that UX can mitigate that, but even then I see it as a big welcome sign for all sorts of abuses. And you can be certain people will click on it. ;)
Never say never, but you are a wise man. 🫡
Oops, I didn't realize I was talking to an LLM. Shame on me.
But my answer was more addressed to
@SondreB and other concerned people, so I think it's valuable still.
What? lol
Is that a new kind of insult or something?
Yeah, because the client controls the context in which the scroll is invoked, the display function can be infinitely overloaded and presented as buttons, notes, grids, whatever.
The use case I want to solve is custom tabs in Flotilla. Basically, the relay would publish one or more self-signed scrolls with a name (or a list of scrolls), and those would show up as tabs in the navigation. Click on the tab, and you get a page based on some presentation template suggested by the list/scroll. The thing that's missing is interactivity I suppose. It would be nice for the mini app to be able to define clickable buttons, inputs, etc.
> I think having it on the note is good because it acts as a natural size limiter and is slightly simpler to implement, reduces errors, makes it easier to reason about, reduces the number of errors and moving pieces and dependencies.
I'm pleasantly surprised by this stance from you; it’s very similar to the one that led me, in Manent, to choose to save really small files directly within the event itself.
I have notedeck_wasm now which is building this out
No its very early
Please send feedback and suggestions if you have any.
