-
@ 266815e0:6cd408a5
2025-02-18 17:25:31
## noStrudel
Released another major version of noStrudel v0.42.0
Which included a few new features and a lot of cleanup
nostr:naddr1qvzqqqr4gupzqfngzhsvjggdlgeycm96x4emzjlwf8dyyzdfg4hefp89zpkdgz99qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzfmhxue69uhkummnw3e82efwvdhk6tcqp3hx7um5wf6kgetv956ry6rmhwr
## Blossom
On the blossom front there where a few more PRs
- Expanded the documentation around CORS headers in BUD-01 thanks to nostr:npub1a6we08n7zsv2na689whc9hykpq4q6sj3kaauk9c2dm8vj0adlajq7w0tyc
- Made auth optional on the `/upload` endpoint [PR](https://github.com/hzrd149/blossom/pull/33)
- Added a `HEAD /media` endpoint for BUD-05 [PR](https://github.com/hzrd149/blossom/pull/42)
- Added range request recommendations to BUD-01 [PR](https://github.com/hzrd149/blossom/pull/47)
With blossom uploads starting to be supported in more nostr clients users where starting to ask where to find a list of blossom servers. so I created a simple nostr client that allows users to post servers and leave reviews
[blossomservers.com](https://blossomservers.com)
Its still very much a work in progress (needs login and server and review editing)
The source is on [github](https://github.com/hzrd149/blossomservers)
I also started another project to create a simple account based paid blossom server [blossom-account-server](https://github.com/hzrd149/blossom-account-server)
Unfortunately I got sidetracked and I didn't have the time to give it the attention it needs to get it over the finish line
## Smaller projects
- [cherry-tree](https://github.com/hzrd149/cherry-tree) A small app for uploading chunked blobs to blossom servers (with cashu payment support)
- [vite-plugin-funding](https://github.com/hzrd149/vite-plugin-funding) A vite plugin to collect and expose package "funding" to the app
- [node-red-contrib-rx-nostr](https://github.com/hzrd149/node-red-contrib-rx-nostr) The start of a node-red package for rx-nostr. if your interested please help
- [node-red-contrib-applesauce](https://github.com/hzrd149/node-red-contrib-applesauce) The start of a node-red package for applesauce. I probably wont finish it so any help it welcome
## Plans for 2025
I have a few vague ideas of what I want to work on Q1 of 2025. but there are a few things i know for certain.
I'm going to keep refactoring noStrudel by moving core logic out into [applesauce](https://hzrd149.github.io/applesauce/) and making it more modular. This should make noStrudel more reliable and hopefully allow me to create and maintain more apps with less code
And I'm going to write tests. tests for everything. hopefully tests for all the libraries and apps I've created in 2024.
A lot of the code I wrote in 2024 was hacky code to see if things could work. and while its been working pretty well I'm starting to forget the details of of the code I wrote so I cant be sure if it still works or how well it works.
So my solution is to write tests, lots of tests :)
-
@ fd208ee8:0fd927c1
2025-02-15 07:37:01
E-cash are coupons or tokens for Bitcoin, or Bitcoin debt notes that the mint issues. The e-cash states, essentially, "IoU 2900 sats".
They're redeemable for Bitcoin on Lightning (hard money), and therefore can be used as cash (softer money), so long as the mint has a good reputation. That means that they're less fungible than Lightning because the e-cash from one mint can be more or less valuable than the e-cash from another. If a mint is buggy, offline, or disappears, then the e-cash is unreedemable.
It also means that e-cash is more anonymous than Lightning, and that the sender and receiver's wallets don't need to be online, to transact. Nutzaps now add the possibility of parking transactions one level farther out, on a relay. The same relays that cannot keep npub profiles and follow lists consistent will now do monetary transactions.
What we then have is
* a **transaction on a relay** that triggers
* a **transaction on a mint** that triggers
* a **transaction on Lightning** that triggers
* a **transaction on Bitcoin**.
Which means that every relay that stores the nuts is part of a wildcat banking system. Which is fine, but relay operators should consider whether they wish to carry the associated risks and liabilities. They should also be aware that they should implement the appropriate features in their relay, such as expiration tags (nuts rot after 2 weeks), and to make sure that only expired nuts are deleted.
There will be plenty of specialized relays for this, so don't feel pressured to join in, and research the topic carefully, for yourself.
https://github.com/nostr-protocol/nips/blob/master/60.md
https://github.com/nostr-protocol/nips/blob/master/61.md