Since the last thing I talked about has been merged I've been bouncing between a few things

SN is integrating CLINK so there's been a few tweaks to that and the Lightning.Pub implementation. Marinading now on an addition to the spec given SN's hybrid model of being a centralized service with its own identity but also having it's wallet connections all client-side and not service initiated... Since it's foregoing using it's service identity in the wallet it will only get some of the benefits/UX of ndebit, but I think it's solvable. h/t to @ek for forging through integration and providing feedback.

The other thing most time has gone into is something that should have been a quick POC but now I'm on week 2 and it feels barely started. Been working with Straycat's graperank from a neo4j graph to power a namespace-by-consensus system.

Decentralized name systems get talked about a lot, and there are countless attempts to solve it (including past efforts of my own). #462059

This approach isn't name to IP but name to pubkey, is non-authoritative, and names are occupied only through social consensus based on the social graph. The goal is that you predictably have a name/slug on nostr that works across most Nostr apps.

The incentives of such a system are so simple in hindsight, if an app goes against social consensus of who occupies a name then their own reputation in the graph declines... everyone has incentive to speak the same language of names. It solves squatting, censorship, and pretty much any proplem with namespace systems you can think of. Disparate algorithms that power indexers should generally get the same results just by nature of the graph.

The "product" side of this is we can help new users pick a name or slug that isn't going to collide with someone who's reputation they are unlikely to over-come, also makes AI suggestions possible. I want this for myself to help us issue Lightning Address and Lightning.Video channels.

Biggest blocker has been ingestion of the graph data into SQL via attestations, the number is large and Nostr relays suck at transferring that... been debugging pagination methods off and on for weeks... grr...