• npub.world
• Vertex crawler
• Vertex Relay and DVMs
• rely
• New DVM spec
• Looking at the future

This is what has been achieved on a per-project basis since receiving the grant from Opensats.

§npub.world

Together with @franzap, I have been refining npub.world to deliver real-time, WoT-powered profile search. These refinements include:

• implementing new desings by @@t3gd…upxq

• moving to the new Vertex DVM standard

• improved URL and npub parsing

§Vertex crawler

Due to the architectural mistakes I made when designing the first version, I have embarked on a full rewrite of the crawler. The new architecture is simpler, more modular and more performant, and I am confident that it will provide a stable foundation on which to expand the Vertex offering with additional functionalities and analytics.

The major differences with the old version are:

• the DB and RWS interfaces have been broken up and simplified into smaller ones, each defined by their own packages

• a simplified, more efficient algorithm for updating random walks

• use of a custom-built cache to speed up graph computations

• a worker pool pattern to speed up event archiving

These changes have reduced the LOC by more than half while improving performance by ~10x. Of independent interest is the new pipe package, which can also be used by other projects to crawl the Nostr network.

§Vertex Relay and DVMs

The Vertex relay has been updated several times, and now supports four DVM services:

• Verify Reputation

• Recommend Follows

• Rank Profiles

• Search Profile

For each service, customers can choose the algorithm to use by specifing the sort option to use between:

• followerCount

• globalPagerank

• personalizedPagerank

More information can be found at https://vertexlab.io/.

Overall, the relay has processed more than 100,000 DVM requests, with the current daily rate standing at around 1,500.

§rely

Unsatisfied with the khatru relay framework, I’ve decided to build my own called rely, with the goal of being simpler and more stable. I’ve not just scratched a personal hitch: I’ve used khatru for several months now (the Vertex relay is still using it) and I encountered several issues, some of which I’ve solved with PRs to the underlying go-nostr library.

The main differences between khatru and rely:

• rely is much simpler, both architecturally and in terms of LOC (less than half)

• rely has a solid testing approach, where a random yet reproducible high traffic hits the relay to see what breaks

• rely implements a worker pool pattern where a configurable number of goroutines process the incoming requests from clients. On the other hand, khatru process them in the HandleWebsocket goroutine, which is spawned every time a client connects. This is dangerous in my opinion because if too many clients connect, memory usage would spike and the relay could potentially crash.

§New DVM spec

I helped to draft this new proposal to update the DVM spec, which is one of the most controversial NIPs. While almost everyone agrees that it needs to change, there is no consensus on how to move forward. I believe our proposal is a sensible approach that defines discovery, usage, and error patterns while leaving flexibility for specific DVM kinds.

§Looking at the future

Next I am going to move the Vertex relay to the rely framework and to the new crawler package. I expect that this will increase the performance and will make things more solid and more simple. After all of this refactoring and simplification, it will be time to finally add features to the Vertex offering. I have an ambitious roadmap consisting of:

• accepting ecash for DVM requests

• designing client-side validation schemes for the DVM responses

• expanding the pagerank algorithm to make use of mutes and reports

• adding an WoT impersonator check to npub.world

• adding a nip05 check to npub.world

• make a relystore package with some plug&play databases for rely.