You write too much danmaku Cody 😆
Jokes aside, it might be rate-limited to 6-10 event/minute 😅
nostr:npub1qny3tkh0acurzla8x3zy4nhrjz5zd8l9sy9jys09umwng00manysew95gx why don't you do long term support for this 10x dev on nostr? (possibly more than 10x!)
Yes, nostr:npub1qny3tkh0acurzla8x3zy4nhrjz5zd8l9sy9jys09umwng00manysew95gx it will be great. Hopefully nostr:npub10pensatlcfwktnvjjw2dtem38n6rvw8g6fv73h84cuacxn4c28eqyfn34f consider to give LTS grants for Doug ...
You can probably try RTX3060 as it is one of the best price/performance consumer GPU. It has 12GB VRAM enough to run LLM with some 13B model and under
I just tagged strfry 1.0.0. Here are some of the highlights:
* negentropy protocol 1: This is the result of a lot of R&D on different syncing protocols, trying to find the best fit for nostr. I'm pretty excited about the result. Negentropy sync has now been allocated NIP 77.
* Better error messages for users and operators.
* Docs have been updated and refreshed.
* Lots of optimisations: Better CPU/memory usage, smaller DBs.
Export/import has been sped up a lot: 10x faster or more. This should help reduce the pain of DB upgrades (which is required for this release). Instructions on upgrading are available here:
https://github.com/hoytech/strfry?tab=readme-ov-file#db-upgrade
Thanks to everyone who has helped develop/debug/test strfry over the past 2 years, and for all the kind words and encouragement. The nostr community rocks!
We've got a few things in the pipeline for strfry:
* strfry proxy: This will be a new feature for the router that enables intelligent reverse proxying for the nostr protocol. This will help scale up mega-sized relays by allowing the storage and processing workload to be split across multiple independent machines. Various partitioning schemes will be supported depending on performance and redundancy requirements. The front-end router instances will perform multiple concurrent nostr queries to the backend relays, and merge their results into a single stream for the original client.
* As well as scaling up, reverse proxying can also help scale down. By dynamically incorporating relay list settings (NIP-65), nostr queries can be satisfied by proxying requests to external relays on behalf of a client and merging the results together along with any matching cached local events. Negentropy will be used where possible to avoid wasting bandwidth on duplicate events.
* Archival mode: Currently strfry stores all events fully indexed in its main DB, along with their full JSON representations (optionally zstd dictionary compressed). For old events that are queried infrequently, space usage can be reduced considerably. As well as deindexing, we are planning on taking advantage of columnar storage, aggregation of reaction events, and other tricks. This will play nicely with strfry proxy, and events can gradually migrate to the archival relays.
* Last but not least, our website https://oddbean.com is going to get some love. Custom algorithms, search, bugfixes, better relay coverage, and more!
Thank you Doug 🙏
Thanks to nostr:npub1q3sle0kvfsehgsuexttt3ugjd8xdklxfwwkh559wxckmzddywnws6cd26p codebase. I just recently implement a Generic API Policy for nfrelay.app to handle RplyFamily spam. Although, example of API server has not fully written yet but feel free to take a look 😄
Friendship ended with #SQLite. Now #PGlite is my best friend.
https://gitlab.com/soapbox-pub/ditto/-/merge_requests/485
#Ditto
How many of performance improvements for Ditto on your personal test compared to using SQLite nostr:npub1q3sle0kvfsehgsuexttt3ugjd8xdklxfwwkh559wxckmzddywnws6cd26p ? 👀
"Never in my life has something so important fallen into my lap, and I feel responsible to the future of humanity to get this right."
— nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c
Congratulations nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c 🎉
Traffic statistic becomes normal again
PSA:
Dear nfrelay.app users, spam filter to handle RplyFamily (R*plyGuy and R*plyGirl) has been used to mitigate the issue. We will update the pattern accordingly. Let us know if you have still found the spam while browsing global feed. Thank you. 🙂
#NostrFilterRelay
Thank you, truly dedicated for archiving every notes 🙏
Baik om. Selamat aktif kembali, lama tak terlihat. Semoga dalam keadaan yg semakin baik ya 🙂
nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z If you need samples of NIP-32 label, there are already lot of tagged event in nfrelay.app including Language label. Feel free to test and use it. 🙂
nak req -k 1985 nfrelay.app , as examples.
Now you give RplyFamily idea 😆
One way to help Nostr grow would to make it easier to find content in languages you speak. Damus and others have nifty ‘translate this note’ features but there’s something different from the way people speak in their own langauge.
Nostr already has the nips for this: https://github.com/nostr-protocol/nips/blob/master/32.md
We can easily add tags to events which would let clients request only events in a specific language, or set of languages. But do any clients write out the language tag and do any use it in the UI for helping people discover content in their own langauge?
I’m thinking of this because most Brazilians prefer to talk to people in their own language, Brazilian Portuguese (yes it’s different written language than Portuguese du Portugal).
It’d be so cool to have on boarding which saw that a user is in Brazil, or has their device set to pt-br and then show them primarily content in their own language. This is also true of Thai, Japanese, and Chinese which also have big sets of Nostr users. The latter two seem to use custom local Nostr clients to avoid this problem. I’m not sure what Thai users do. I know that although I speak Spanish, and there are lots of hispanohablantes on Nostr, we mostly seem to write in English. That’s because it’s hard to filter out by language community except for who you choose to put in your contact list.
So, what Nostr clients do this well? How do get clients writing these language tags in their posts and make it so clients then display / use them for users.
Unfortunately, there is no specific setting yet to filter language in major clients. At most clients will directly translate into 'best guess' target language like Amethyst and Damus (Purple member) done.
Currently nfrelay.app provides NIP-32 event for language labelling. Hopefully more labeller comes and client can pick up and choose data freely.
Rabble, does nostr:npub12m2t8433p7kmw22t0uzp426xn30lezv3kxcmxvvcrwt2y3hk4ejsvre68j process all notes or dedicated to followers of tagr bot only ? I wonder if it will be affected with surging traffic like BlueSky in the future
Thank you Cody, done 🫂
This is for small project that only need small bandwidth for now. I haven't prepare dedicated ISP with public IP yet, so it will be connected to one of my VPS through wireguard later. VPS will route traffic into this PC.
Just set up my first PC as a home server. I finally don’t need to rent a server quite often. 😊
Today I will write a #WoT plugin for https://github.com/CodyTseng/nostr-relay
and add it to https://github.com/CodyTseng/nostr-relay-nestjs
and https://github.com/CodyTseng/nostr-relay-tray
Once I find a way to leave my comfortable bed ☺️
Take a rest Cody, don't let RplyGuy wake you up 😄
Seems no one know, mattn-san 😅
But at least, most likely they are experienced nostr devs who might be bored or just want to push improvement in relays and clients
Oh, do you mean this one?
It is my bot using old event format (kind:9978). It seems there are other people who blast those event. I only publish in nfrelay.app 😅
The pubkey of nostr-filter-relay bot is 981b00cd897786f2a40578c337984d8f0912397c3c6dfc6ffebd4d896cf93f4f .
I think gitworkshop can filter only kind 1, kind 7, and git events to show in the UI.
nostr:npub12m2t8433p7kmw22t0uzp426xn30lezv3kxcmxvvcrwt2y3hk4ejsvre68j might be the popular one . The report is clearly visible due to kind 1984 usage 😄
Also, I haven't change my inbox relay yet. The issue seems affecting on UI side
I think it works. This is event id of the last job response
3a0053d8a13fefe6d99fb217153c54d05dad44083ea0b59693d2c2ac6cf77c22
But, It seems it was stuck in the Amethyst UI. Do i need to update my Amethyst? Currently using v0.89.10
Oh, Did you implement custom search on local cached notes? I remember that you used strfry which have no support for NIP-50?
Btw, i tried 2 times and it seems always stuck in here despite paying succesfully 😅
