Profile: 738ea36e...

Replying to Avatar PABLOF7z

nostr:npub1ww82xmhhfv4vszlm8zrmgp3hclwd7a82dmkh83cckuvnxyaep7dsnyxmjl replies don't tag the event that it was replied to? That would be amazing.

So you can navigate directly to the thread event from any message? noted for future threads.

Replying to 738ea36e...

I've been dabbling with Nostr packages lately and decided to experiment by creating a real-time mirror of the Bitcoin Mailing List on Nostr, going back to 2011πŸ‘΄

nostr:npub15g7m7mrveqlpfnpa7njke3ccghmpryyqsn87vg8g8eqvqmxd60gqmx08lk

To help catch up on discussions, threads from 2011 and 2023 with multiple responses include AI generated summaries πŸ€–. If this sparks interest, I might expand this feature.

Each sender has an archive account for easy access to all their messages and stats πŸ“¬. The best part is that there's no moderation here - I believe in client-side filtering.

Considering making it two-way: zapped notes could bounce back to the mailing list based on popularity. πŸ”„ What's your take?

Please note, due to rate limits, it's not on all popular relays. However, for those of you who run a fancy relay and would like to store a backup, I can provide the full npubs whitelistπŸ”’

Lightning mailing list is coming next!⚑️

Using nostr:npub1ndk0nwqwjajykt5fnlyjhdlp33dffurcmx5vfp2hljp2y7ew62fsq7qfy4 for this was straightforward, shoutout to nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft and the team! Feedback is welcome, let me know your thoughts!

nostr:npub1qgwhaaa2lsp54rl0hfx7qa3z678ax6wlre0em475rhpvl7n54cpqgg7y7n

https://void.cat/d/UZpkYKpLJZ9rSHVMF61eZa.webp

The harsh reality for developers is that once you begin exploring the world of uncensorable, programmable money and social network, turning back becomes almost unthinkable.

Yea, and they probably don't allow the creation of hundreds of new archive profiles πŸ˜„

I've been dabbling with Nostr packages lately and decided to experiment by creating a real-time mirror of the Bitcoin Mailing List on Nostr, going back to 2011πŸ‘΄

nostr:npub15g7m7mrveqlpfnpa7njke3ccghmpryyqsn87vg8g8eqvqmxd60gqmx08lk

To help catch up on discussions, threads from 2011 and 2023 with multiple responses include AI generated summaries πŸ€–. If this sparks interest, I might expand this feature.

Each sender has an archive account for easy access to all their messages and stats πŸ“¬. The best part is that there's no moderation here - I believe in client-side filtering.

Considering making it two-way: zapped notes could bounce back to the mailing list based on popularity. πŸ”„ What's your take?

Please note, due to rate limits, it's not on all popular relays. However, for those of you who run a fancy relay and would like to store a backup, I can provide the full npubs whitelistπŸ”’

Lightning mailing list is coming next!⚑️

Using nostr:npub1ndk0nwqwjajykt5fnlyjhdlp33dffurcmx5vfp2hljp2y7ew62fsq7qfy4 for this was straightforward, shoutout to nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft and the team! Feedback is welcome, let me know your thoughts!

nostr:npub1qgwhaaa2lsp54rl0hfx7qa3z678ax6wlre0em475rhpvl7n54cpqgg7y7n

https://void.cat/d/UZpkYKpLJZ9rSHVMF61eZa.webp

Are there any stable relays (paid is also fine) I can use to upload few Kb's of text (lots of notes) without getting rate-limited or npub-limited?

Replying to Avatar jb55

πŸ‘€

The Bookkeeper plugin has arrived at

nostr:npub1lzmk2evgs4hryjg5hnv3h6cj7fl3qa6nqnxazs9udap3krgr9rpq2w2q9x

as well βœ¨πŸ‘€

Connect your browser to your

nostr:npub1jg552aulj07skd6e7y2hu0vl5g8nl5jvfw8jhn6jpjk0vjd0waksvl6n8n CLN

node and request the bookkeeper plugin as if you were 5 years old. With the commando plugin your node can securely forward the output, now even parsing zaps courtesy of nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s!

And finally, export all to any #nostr relay.

In need of a break from Lightning? Create a fun image of Satoshi! πŸ‘€

https://youtu.be/0EiA1pJGI4M

Definitely, that was my first idea. But I'm pondering if there's a method that fits this scenario better. Instead of providing an app access to all decrypted dms, how about granting access only to particular necessary (unencrypted) keys? It'd also be a more precise and secure way to share private data across apps.

From my viewpoint, the relay doesn't need to implement signing or undergo any changes. To put it into perspective with my current situation, user's browser is storing private node data, say, a CLN rune. Whenever a user switches a browser or clears the local storage, they're required to re-enter the data.

The workaround I've considered involves my app generating a "vault-store" event. The user's extension would then encrypt it, sign it, and broadcast it to the relays.

Following this, when the user logs back in via nostr, my app could request the extension to decrypt the value and re-store it in the browser's local storage.

What do you think?

Fascinating! is the code publicly available?

My concern is it's aimed more towards power-users with dedicated hardware running the nsecbunker daemon.

I've been envisioning something simpler to kick things off: a "Vault data" event kind ({vault_key -> encrypted_data}), which can be stored on public relays. Apps could then pull all npub's vault keys and request continuous read/write permissions for specific keys through an extension.

This approach eliminates the reliance on the browser's local storage as the "long-term" memory for personal data, as everything can be restored from the vault.

It's a basic idea in need of more thought

Is it a new relay implementation for Mac? wouldn't something like a new event for an encrypted key-val and some work on the extension be enough?

Replying to Avatar PABLOF7z

didn't read this thread, but are you referring to nsecBunker, nostr:npub1ujsax5qggxkmvu6gwht9c30p0w2df56akngj3hfg3j3cr7daejgq2nnzxc ?

I recorded this poor-man-demo video this morning:

https://pablof7z.com/images/nsec.mov

after publishing this note:

nostr:note1hvys0eq2c9jwrz6sqwvqznmzwaa2hnsf4lg4rfq49ftxzrtwgnesxzqur0

That's really neat! I just want to clarify a few things - it seems like the nsecBunkerClient has to stay online and listens out for "note signature requests", right? And then, it approves these requests based on a certain set of rules? Where are these rules stored? Do you have plans to evolve it for more complex rule sets? (for example, "a specific npub is authorized to post on my behalf for the next hour only and a max of 5 notes")

However, I think what I'm searching for is slightly different. I'm envisioning something like a private vault (think Amazon's style, but implemented on nostr relays). My application would then ask the extension for read/write permissions for a specific key in this encrypted vault. After a user logs in with nostr, the app could ask for access to some of the user's private data, pending the user's approval.

Down the line, this could be integrated with nsecBunkerClient. In this scenario, you could allow another npub access to your private vault. The client would manage the decryption and encryption for that user, following a set of specified rules.

Replying to 738ea36e...

Take a look at the beta version over here: https://autobtc.ai nostr:npub1lzmk2evgs4hryjg5hnv3h6cj7fl3qa6nqnxazs9udap3krgr9rpq2w2q9x

Right now, private data, like a rune to connect to a CLN node (along with some other user preferences) is stored in the browser's local storage. But I've got my eye on expanding it to a multi-rune/macaroons data storage system. It'd be killer if users could log in and out from different browsers, and their client could securely pull this data from a dedicated "Nostr-vault". Any thoughts?

So, when I'm talking about a "client", I'm mainly referring to AutoBTC.ai at present. But down the line, we might see other clients cropping up. These potential clients could be designed to request permissions for reading specific values from that secure vault.

If there's no existing solution for this, I might just put forth a NIP to address it.

Take a look at the beta version over here: https://autobtc.ai nostr:npub1lzmk2evgs4hryjg5hnv3h6cj7fl3qa6nqnxazs9udap3krgr9rpq2w2q9x

Right now, private data, like a rune to connect to a CLN node (along with some other user preferences) is stored in the browser's local storage. But I've got my eye on expanding it to a multi-rune/macaroons data storage system. It'd be killer if users could log in and out from different browsers, and their client could securely pull this data from a dedicated "Nostr-vault". Any thoughts?