What creative ideas have you been rambling on? \ stacker news ~Design

pull down to refresh

What creative ideas have you been rambling on?

188 sats \ 1 comment \ @deSign_r 16 Sep Design

This post is part of a series. It is meant to be a place for stackers to discuss creative projects they have been working on, or ideas they are aiming to build. Regardless of your project being personal, professional, physical, digital, or even simply an idea to brainstorm together.

If you have any creative projects or ideas that you have been working on or want to eventually work on... This is a place for discussing those, gather initial feedback and feel more energetic on bringing it to the next level.

Thanks @bounty_hunter @anon @billytheked @justin_shocknet @django @ACYK @Kontext for joining and sharing your ideas in the previous edition. How are you all doing with your projects? Any update?

₿e Creative, have Fun! :D

#1207913 ↩

125 sats \ 0 replies \ @justin_shocknet 4h

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...

Footnotes