I see. Glad to hear then.
What do you think about multiple label "l" structure that i have shown in language or topic labelling? Do i need to change something in those cases?
Example:
Note/post which has multiple languages
["l","en","ISO-639-1"], ["l","ja","ISO-639-1"]
Note/post which has multiple topics
["l","science_and_technology","app.nfrelay.topic"], ["l","arts_and_culture","app.nfrelay.topic"]
Thank you. I think i want to make sure about label namespace.
Is it ok to state "L" namespace multiple times as long as it was clear which reference of the namespace? In language labelling i made two namespace using "ISO-639-1" for public use (different apps/clients can freely query it) and "app.nfrelay.language" for internal use.
Yes, agree. Possibly with Freemium model. Free with short term storage and paid with long term storage.
Not exactly same, i have little experiment to store only 7 days old of events. All events excluding main metadata event (0, 3, 10002) will be deleted if they were 7 days old. Metadata events were not deleted. It only takes around 10 GB of storage.
It was feasible plan for free relays to do something like this.
#asknostr
Hi nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr3mhxue69uhksmmyd33x7epwvdhhyctrd3jjuar0dak8xtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0ss9zgs nostr:nprofile1qqspwwwexlwgcrrnwz4zwkze8rq3ncjug8mvgsd96dxx6wzs8ccndmcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qtxwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tmwwp6kyvt6w46kz6nyxa6nxumc8pu82wfj09shvwt2wau8qu3cxvukxuesdd3nxufkws6nvanyx46njufsxvehsmtgwd4nvcejw43n7cnjdaskgcmpwd6r6arjw4jszxrhwden5te0dehhxarj9enx6apwwa5h5tnzd9az77vr4lw and other nostriches who might be familiar with NIP-32.
Currently, i'm preparing to migrate custom label event (kind 9978) into NIP-32 event.
What is the best way to preserve the old event data structure while maintaining compatibility with NIP-32 structure?
The structure of the old event and the new proposed event (NIP-32 compatible) has been documented here:
https://github.com/atrifat/nostr-filter-relay/issues/18
Any feedback and suggestions are really appreciated. Thank you.
Hi nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr3mhxue69uhksmmyd33x7epwvdhhyctrd3jjuar0dak8xtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0ss9zgs , would you mind to take a look at this? I need some suggestions related to NIP-32 π
Congratulations π
Ini yang benar-benar mendekati gambar di bungkusnya π
#asknostr
Hi nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr3mhxue69uhksmmyd33x7epwvdhhyctrd3jjuar0dak8xtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0ss9zgs nostr:nprofile1qqspwwwexlwgcrrnwz4zwkze8rq3ncjug8mvgsd96dxx6wzs8ccndmcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qtxwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tmwwp6kyvt6w46kz6nyxa6nxumc8pu82wfj09shvwt2wau8qu3cxvukxuesdd3nxufkws6nvanyx46njufsxvehsmtgwd4nvcejw43n7cnjdaskgcmpwd6r6arjw4jszxrhwden5te0dehhxarj9enx6apwwa5h5tnzd9az77vr4lw and other nostriches who might be familiar with NIP-32.
Currently, i'm preparing to migrate custom label event (kind 9978) into NIP-32 event.
What is the best way to preserve the old event data structure while maintaining compatibility with NIP-32 structure?
The structure of the old event and the new proposed event (NIP-32 compatible) has been documented here:
https://github.com/atrifat/nostr-filter-relay/issues/18
Any feedback and suggestions are really appreciated. Thank you.
Oh, kirain ada komunitas aktifnya. Contohnya Bitcoiner Thailand (Siamstr) kan aktif di X dan juga Nostr. Barangkali kita juga banyak π
Ini jelas, nostr:npub19dn7fq9hlxwjsdtgf28hyakcdmd73cccaf2u7a7vl42echey7ezs2hwja7 pakainya github π€£
Udah lama banget mas gak pakai X terakhir zaman kuliah kayaknya bertahun-tahun yang lalu π
Apa di X banyak mas komunitas bitcoin oleh warga nusantara? Saya sudah lama tidak pakai X lagi π
Mix of Nostrmo, Amethyst, Nostrudel, and 0xChat
I see, it is quite hard for critical computation that need fast processing (< 100 ms) especially if the implementation can't be rewritten totally.
Based on your experiences, is it possible to generate zk proof for external API request? Or is it limited to computation that was calculated directly on host machine?
Examples:
1. We provide DVM that gives weather data that were processed from external weather Rest API service
2. Text Summary DVM that gives summary after request them into external AI service (GPT4, Lllama3.1 405, etc) due to can't self host it
Both cases need external service
I see, it is quite hard for critical computation that need fast processing (< 100 ms) especially if the implementation can't be rewritten totally.
Based on your experiences, is it possible to generate zk proof for external API request?
Examples:
1. We provide DVM that gives weather data that were processed from external weather Red API service
Oh, I think many devs who are not familiar with ZK proof might choose second aproach due to minimum modification of the original code or they just can't due to all dependencies which hard to be rewriten all over. π
> However there is big overhead
Does it slow down much to generate the proof along the code? More than 1000ms?
Powering Verifiable Computation for the Nostr Revolution:
https://hackmd.io/@abdelhamid/nostr-dvm-verifiable-computation
#Nostr #FreedomOfSpeech #Integrity
Hi Abdel, thank you for giving showcase on using ZK Proofs as verifiable DVM. It is interesting case and love your work.
I have no experince yet integrate ZK Proofs in practical application. Given these following function:
How do we implement ZK proofs in those "predict" function?
Update:
Will recently shared his dedicated server info for Damus Relay
Congratulations Tsururun-san, wish you in a good way π

