LND provides pretty good data on "pending" balances and "sweeps" but as Alby Hub is LDK, I don't know how easy it is to access that data.
The solution is to do AI stuff in docker. I never attempt to use venv or anything directly on the host machine.
I'm building a solution that relays and apps can use to flag very bad/shocking image urls, without relying on brittle solutions like domain blacklists. Turning out to be more complicated than I first thought but should have something ready to test within the next week nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
Wouldn't it be great if nostr:npub1dergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsh9xzpc's and nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft's new podcast could be referenced directly inside Nostr? That way I wouldn't have to just allude to its existence and could make clear what I'm talking about instead of hoping the reader of this tweet will search for some vague name in a centralized canonical index of all podcasts.
What is the name of the podcast ?
We've written our own but it's based on Ruby on Rails and I'd understand if that's not your thing.
I like digital ocean but I'd like someone to tell me that something else is better so I can try it.
nostr:npub1yzvxlwp7wawed5vgefwfmugvumtp8c8t0etk3g8sky4n0ndvyxesnxrf8q I had complained a few days ago that nostr:npub1yzvxlwp7wawed5vgefwfmugvumtp8c8t0etk3g8sky4n0ndvyxesnxrf8q would over time get really slow in the browser, and that this could be fixed by clearing local storage. I now have a theory that this problem is limited only to BRAVE -- I am using Chrome now and not seeing this issue. I will follow up if it slows down again in Chrome. I think Brave's local storage might not be as fast/good.
nostr:npub1lxktpvp5cnq3wl5ctu2x88e30mc0ahh8v47qvzc5dmneqqjrzlkqpm5xlc and other nostr:npub1jluy3twvf338v6zlujzzdhjkzjy8ezj34ksydr8vw8a6jwp89ygshpp2kq users... there is an issue I discovered, if a payer tries to zap a nostr:npub1jluy3twvf338v6zlujzzdhjkzjy8ezj34ksydr8vw8a6jwp89ygshpp2kq user and the PAYER has a LOT of relays set up .... that the zap will fail, I understand the problem now, hope to have it fixed shortly.
We rolled out out a fix for this about 10 minutes ago. If you have any zaps that fail to complete, or any other zap issues, pls let me know. thanks.
nostr:npub1lxktpvp5cnq3wl5ctu2x88e30mc0ahh8v47qvzc5dmneqqjrzlkqpm5xlc and other nostr:npub1jluy3twvf338v6zlujzzdhjkzjy8ezj34ksydr8vw8a6jwp89ygshpp2kq users... there is an issue I discovered, if a payer tries to zap a nostr:npub1jluy3twvf338v6zlujzzdhjkzjy8ezj34ksydr8vw8a6jwp89ygshpp2kq user and the PAYER has a LOT of relays set up .... that the zap will fail, I understand the problem now, hope to have it fixed shortly.
Yeah, it's totally fucked up. We need to fix this.
Got it.
Thanks.
I think the implementation bug is a bug in MY implementation (I wonder if others have done this too...) I interpreted "where the description is this zap request note and this note only" to mean that I HAD to put the FULL note into the description.
What you are suggesting, I think, would read like this if it were explained in the spec:
"...where the description is this zap request note and this note only, unless it's too long, in which case you can put a hash of this note in the description_hash field, then you can put something else in the description field, like the note truncated to fit the available length"
I wonder if the nip-57 spec should be tweaked to mention this.
I don’t think this relates to NWC. I know it’s confusing, I had to go over that ground for a bit to realize (I think) that this is only related to NIP57.
nostr:npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s and nostr:npub1sy5awfp57rlmak0c3mz6c9zpddamzzq9yuty60qlvs7msggg06xs5ndhej and nostr:npub1kwhxtsq92uw5emgmy6d56dascpzkxjjeh7d8xu7zrljjzj3k73yspf9h5l
I'm tagging you because I think you will most efficiently be able to tell me if I've confusing myself or if I have actually discovered an issue in the ZAP spec , nip-57 ... https://github.com/nostr-protocol/nips/blob/master/57.md ..
I am finding that when the SENDER of a zap has configured too many relays... like 10+.... then when the SENDER constructs the zap note...
.... the zap note can get TOO LONG.
Because, according to the spec, the recipient's server must do this:
"the server should fetch a description hash invoice where the description is this zap request note and this note only"
in other words: we need to stuff the text of this note into the description field of the invoice!
... so what happens if there are too many relays is that this note gets to be TOO LONG, and when we ask LND to make the invoice, we get...
Error creating invoice: [
503,
'AddInvoiceError',
{
err: Error: 2 UNKNOWN: memo too large: 1097 bytes (maxsize=1024)
This might seem like a theoretical problem but I can reproduce the issue by using #coracle ... adding a bunch of relays manually, and then trying to zap a note whose recipient is using an LND node... I can see that the LND node fails to generate the invoice with a "AddInvoiceError" ("memo too large").
And then, to make the problem go away, I can go back to Coracle, reduce my number of relays, and then I can send zaps fine, because the descriptions fall under LND's max-length.....
Now, of course, I could go and ask LND "why don't you allow bigger memos/descriptions" -- but, my guess is that you could do a denial of service attack against a lightning node by requesting a shit-ton of invoices with really big memos... at least you could fill up that node's database, right?
So, please tell me: Am I a pitifully confused developer, or did I discover something that needs to be added/fixed in the nip-57 spec, like should the spec say "Hey, if you are developing a client which is constructing zap requests, if your user has a ton of relays, cool, but don't put more than 4 relays into the zap note..."...
Or, am I just confusing myself and/or reading/implementing the spec, wrong? Or taking too many marijuana edibles?
thanks
Fair point. I guess, I'm fairly new to Nostr, just a few months, and I've seen some pretty horrible things, and then I post about it, and it turns out a lot of OTHER people have seen some pretty horrible things, and recently. So at least I know that:
1) There is a problem
2) The problem is unsolved
It's true I don't know much more than this.
#coracle testing images today, I find I CAN upload an image with a note with the upload button, but if I try to paste it from the clipboard (I'm on a well-known mainstream commercial OS) I see the "UPLOADING MEDIA..." thing for a long time and nothing happens. Also, when I am stuck in "UPLOADING MEDIA..".. it seems whatever I type into the post box will be forever lost because I can't cancel the upload (so far as I can see) and I can't just give up and post the note WITHOUT the uploaded media...
#asknostr among the problems that Nostr faces, the child porn problem is a very, very, very bad problem.
A VERY bad problem.
What is the current thinking among developers about how to deal with this?
Nobody likes censorship, but the only solution I can think of (SO FAR) is running an image identification service that labels dangerous stuff like this, and then broadcasts a list of (images, notes, users?) who are scoring high on the "oh shit this is child porn" metric. Typically these systems just output a float between zero and 1, which is the score....
Is anyone working on this currently?
I have a good deal of experience of running ML services like image identification at scale, so this could be something interesting to work on for the community. (I also have a lot GPU power, and anyway, if you do it right, this actually doesn't take a ton of GPUs to do even for millions of images per day....)
It would seem straightforward to subscribe to all the nostr image uploaders, generate a score with 100 being "definite child porn" and 1 being "not child porn", and then broadcast maybe events of some kind to relays with this "opinion" about the image/media?
Maybe someone from the major clients like nostr:npub1yzvxlwp7wawed5vgefwfmugvumtp8c8t0etk3g8sky4n0ndvyxesnxrf8q or #coracle or nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg or nostr:npub18m76awca3y37hkvuneavuw6pjj4525fw90necxmadrvjg0sdy6qsngq955 has a suggestion on how this should be done.
One way or another, this has to be done. 99.99% percent of normies, the first time they see child porn on #nostr ... if they see it once, they'll never come back.....
Is there an appropriate NIP to look at? nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 ? nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft ? nostr:npub16c0nh3dnadzqpm76uctf5hqhe2lny344zsmpm6feee9p5rdxaa9q586nvr ?
Unpopular opinion: Because of this problem, because of the refusal of relays block image links which contain CSAM, several of the major Nostr apps, possibly including nostr:npub1yzvxlwp7wawed5vgefwfmugvumtp8c8t0etk3g8sky4n0ndvyxesnxrf8q , nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg , and nostr:npub18m76awca3y37hkvuneavuw6pjj4525fw90necxmadrvjg0sdy6qsngq955 will be kicked off the Play Store and App Store. This might happen fairly soon, too. Web applications will be fine and won't be impacted. Relying on "user reports" or "web of trust" is a joke and won't prevent these apps from getting killed by Apple or Google. Sorry.
Complete guide, not for total normies but should be good for anyone with excel-level computer skills... https://rizful.com/get_on_nostr_today
Running nostr:nprofile1qyxhwumn8ghj7mn0wvhxcmmvqyw8wumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctvqqsf07zg4hxyccnkdp07fppxmetpfzru3fg6mgzx3nk8r7af8qnjjygs2hmf7 with lightning address gnzsnz@getalby.com
Hi, how are u running rizful without a Rizful lightning address?
nostr:npub1jluy3twvf338v6zlujzzdhjkzjy8ezj34ksydr8vw8a6jwp89ygshpp2kq users -- we just made some tweaks to the relay that handles NWC connections for Rizful. These tweaks should improve performance and security. If you notice any changes/issues starting from right about now (12:18 AM GMT, Feb 12th)... please let u know right away.. thanks
nostr:npub1yzvxlwp7wawed5vgefwfmugvumtp8c8t0etk3g8sky4n0ndvyxesnxrf8q You may already be aware, but muting users doesn't seem to work in the web app. I can mute posts in a thread with "mute user", then reload the page, and the user is definitely not muted and the notes are still there.
In practice this will mean that only a small number of image domains are whitelisted. This could be a good interim solution.
This is basically a war against illegal and dangerous content. You can’t just nicely ask the other side to politely label their weaponry.
Yes. So any technical solution must not publish a public list of bad content and must not provide search or discovery functionality.
As far as I can tell this is just a nonprofit that has raised some money and so far just has a contact form up.... I don't see any software or apis yet.