thanks for sharing mate. I've used networkx in the past, which I am sure it's slower, but still I found that visualizing a social graph is rarely useful. You just see a buuuunch of arrows and it's very hard to make sense of it

Client devs, if you don't want to reinvent the wheel when it comes to something so crucial as protecting your users from impersonators, you can just use DVM's. WoT then becomes as simple as publishing an event. To see how it would work, you can check npub.world. Just keep in mind that it will become even faster after the refactor is complete. No need to commit straight away, you can test it for free. Learn how at vertexlab.io (thanks Jon for the shout-out)

distance-based WoT can be, but flow-based or random-walk based WoT are much more resistant. example vertexlab.io

thanks, I was fooled by called reposting

wow man, that's really impressive to think about.

the problem of 1. is javascript

this is super cool sir!

it's a good thing to have multiple implementations. Haven is based on khatru (a framework) and I imagine offers a complete experience out of the box. rely is a framework like khatru, overall simpler, less features and "tighter"

thanks for the feedback sir

I haven't posted much in the past month because I have been refactoring almost every aspect of Vertex. These should make the whole stack simpler, faster, and more maintainable. Next, I'll finally approach a big build: - adding mutes to Pagerank (+10%-ish precision) - accepting ecash - adding client-side validation schemes to minimize trust in using Vertex which one should I do? #asknostr

shut up fake italian

the logos are quite nice, maybe the names are quite hard for westerners

Do u mean zaps and reactions in the users notifications? I think that too can be done using RankProfiles. It's unlikely one has thousands of notifications, but not impossible if its targeted by an attacker

yeah but this is true for both your current WoT and the Vertex ranks, no? The way I imagine it is: - a user main feed is based on its follow-list, which is pulled from relays - as the user starts clicking around (search, reading replies...), this calls a service provider like Vertex, and the ranks are stored for later use. So it would progressively load ranks as needed, not ahead of time. Believe me I am not trying to push anything, just trying to genuinely understand.

I am missing something sir. I assume that Coracle stores locally the WoT calculations it computes client-side. Is it true? If so, why can't it store the ranks provided by Vertex in the same way?

It's an interesting idea but I don't see where exactly in the client you would need it. - for the feed one uses follows - for the replies, because on the relatively low number one can use the ranks directly (giving the user the ability to set a threshold). Bloom filters are superior to RankProfiles when you are dealing with +10k pubkeys (not in the follow-list of the user) I think. Am I missing something?

It really depends on the usecase, there is no silver bullet. For example, if you are looking at a product, you could fetch all reviews for that product, and drop reviews from whose pagerank is lower than a threshold. Or you could weight that review using the pagerank (influencers have higher influence, not necessarily a good idea). Or maybe you can show the average vote of the members of the community, which is more contained. All tradeoffs. Pagerank can be run on any graph, so one could built it by looking at who replied/zapped/liked to whom, in a given setting. Also, not all signal should be condensed into a single rank, multiple trust signals should be provided imo. Number of followers, ranks, nip05, badges, all give some clues that your brain can interpret.