Nostr View

I'm very curious nostr:nprofile1qqsw3mfhnrr0l6ll5zzsrtpeufckv2lazc8k3ru5c3wkjtv8vlwngkspz9mhxue69uhkummnw3ezuamfdejj7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3vamnwvaz7tmwdaehgun9d35hgetn9ehhyee0h65qrn nostr:nprofile1qqsr7acdvhf6we9fch94qwhpy0nza36e3tgrtkpku25ppuu80f69kfqpz9mhxue69uhkummnw3ezuamfdejj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09ug4n6q3 nostr:nprofile1qqsr9cvzwc652r4m83d86ykplrnm9dg5gwdvzzn8ameanlvut35wy3gpzpmhxue69uhkummnw3ezuamfdejsz9thwden5te0wfjkccte9ekk7um5wgh8qatzqyt8wumn8ghj7un9d3shjtnswf5k6ctv9ehx2aq38qmrf nostr:nprofile1qqsdv8emcke7k3qqaldwv956tstu40ejg663gdsaayuuujs6pknw7jspp4mhxue69uhkummn9ekx7mqprpmhxue69uhhqun9d45h2mfwwpexjmtpdshxuet5qyf8wumn8ghj7ur4wfcxcetsv9njuetnn9mexk nostr:nprofile1qqszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fgpr3mhxue69uhhxct5v4kxc6t5v5hxs7njvscngwfwvdhk6tcpzfmhxue69uhkummnw3e82efwvdhk6tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsk7wj75 nostr:nprofile1qqsx8lnrrrw9skpulctgzruxm5y7rzlaw64tcf9qpqww9pt0xvzsfmgprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qyvhwumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdshssfnq7m nostr:nprofile1qqs8eseg5zxak2hal8umuaa7laxgxjyll9uhyxp86c522shn9gj8crspz9mhxue69uhkummnw3ezuamfdejj7qgjwaehxw309ahx7um5wgerztnrdakj7qgkwaehxw309a3x2an09ehx7um5wgcjucm0d5hsvlnggv nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgsppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgewaehxw309a5xyu3wvdhhyctrd3jjuum0vd5kzmp0gankr4 nostr:nprofile1qqsyeqqz27jc32pgf8gynqtu90d2mxztykj94k0kmttxu37nk3lrktcpzemhxue69uhk6mr9dd6juun9v9k8jtnvdakz7qg4waehxw309a6x2um59eex2ctv0yhxcmmv9uq3kamnwvaz7tm5dpjkvmmjv4ehgtnwdaehgu339e3k7mf0f6aqk5 nostr:nprofile1qqsx3kq3vkgczq9hmfplc28h687py42yvms3zkyxh8nmkvn0vhkyyuspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9thwden5te0dehhxarj9ehhsarj9ejx2a30qy88wumn8ghj7mn0wvhxcmmv9u0t0nl2 nostr:nevent1qqs29gpyzhdtunlm90kng95rel7eyl5a7kxc0un8y2rv5a3f7rjnzdcprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0qgs8a474cw4lqmapcq8hr7res4nknar2ey34fsffk0k42cjsdyn7yqqrqsqqqqqp4djdju

Jay @Jay - 3d

nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug

Jay @Jay - 3d

I'm just trying to get a real answer to this question.

mleku @mleku - 3d

nostr sorta can have this problem too, thanks to users configuring dozens of relays all of them sending the virtually same content

Jay @Jay - 3d

Thanks 🫡 From the looks of it, it guaranteed that every user's chain of notes was preserved in it's entirety, like a blog. Whereas on Nostr you kinda just yeet your notes into the ether and let the network handle them, but the notes can be interconnected and form more complex structures than simple feeds.

mleku @mleku - 3d

i think it just means it's best to have more intelligence in the relays so they are sharing data of interest to their subscribers, and that the main onboarding obstacle should be about how you monetize that access, because otherwise it's spam and trouble, like what we see happening for some time now with primal's general aggregation the pub/sub model is much easier to aggregate upstream than a simple repository model... but the semantics of it is complicated due to the merging of query and subscribe in one messy mass under "REQ"

Jay @Jay - 3d

For me, I just want a personal relay that contains my web of trust. I plan on incrementing a trust counter between npubs as they interact. By charting the mutuality of engagement between you and your peers, and the volume of notes between you, you can map a "friend zone," and use that set to prevent spam from entering the relay, using yourself as the trust anchor. You and your friends can freely use the relay, since you're going to want to greedily fetch your friends' notes from the network anyway.

mleku @mleku - 3d

yeah, i've thought about this... even have a basic spider framework created for realy but i removed it... it was just gathering current versions of all the whitelisted users' profile/follow/mute lists (which is 11000+ users on my relay just from my follow list, it goes two levels deep to implement a "friends and guests" access model i would quite like to have a spider aggregating at least my direct friends notes, i should write a spider, separate to the relay

Jay @Jay - 3d

Yes, and that's great. But my goal is to ignore follow/mute lists and calculate trust purely on "engagement," i.e. event references.

Jay @Jay - 3d

I'll see how well a WoT can be calculated without follow lists. But I think those lists as a metric for trust are too easily exploited.

mleku @mleku - 3d

so, that would be reply and reaction events you would have to scan the entire event database of a relay to do this, and it would need to create a very large graph table compiling a count on each link as a weight on the vertex between two nostr:npubs it would be a fuzzy value, also... you could probably even have the relay add the weight value to the graph table as soon as the event comes in, computing the graph you probably want to snapshot that table and then create a table of the weights that exceed some criteria for threshold, the top 100, 200, something like this i've thought about it, as you can see, and i think it would be a great thing to add to augment the relay API - so the client could then query for each npub in a set of results to get their vertex weights and set a cut-off level and not show those events, or it could be done on the relay as an extra api extending the filter with a graph weight cut-off spec of some sort the thing is that the follow/mute lists make a neat and relatively cheap mechanism of whitelisting users who are probably not spammers from a designated list of users (subscribers, presumably)... this is the purpose of the WoT whitelisting in #realy this other stuff would be an extended API and clients would be able to also interact with that by an extended filter request that includes a threshold, it would be better to do it on the relay than to waste all that bandwidth and processing on a slow shitty client

Jay @Jay - 3d

I don't even have to jump through all those hoops. Benefits of using neo4j. An event comes in, and I match its author, the event it references, that event's author, and a trust relationship between the npubs. Based on the note kind, you increment a value in the trust relationship. It's also very easy to count the number of event engagements you have to another npub because it's the count of all npub1—event—>event—npub2 paths.

mleku @mleku - 3d

benefit of Go is much smaller executables, and i have total control over how my database actually works down to the last bit the scaling problems won't happen to my stuff because i already built them to scale by using pipelining

Jay @Jay - 3d

I'm so glad that anytime I talk about graph databases, no one gets it. So much job security 😂

mleku @mleku - 3d

haha i know how to WRITE a graph query in Go using badger i'm building a complete graph algorithm for a recommendation engine in my fiat mine job what i described before is pretty much how this thing is implemented, you think i'm "doing too much work" but i can assure you that when i do it, it will get results at 2x the speed

Showing page 1 of 1 pages