Unless some poor soul gets impaled by a peace flag. Then all bets are off. ☮️

Thank you. Nice distinction. While efforts to decentralize the “identity infrastructure” will not alone bring sovereignty to individuals, it will bring each of us (that wishes) closer to being able to realize self sovereignty. The “decentralize” movement can be a bit short sighted, if the end game is self sovereignty. However, it is undeniably “on the path”. Decentralization will bring us closer. So… yea. Were still in alignment with the goal, even if we don’t all see it yet. — This is a comment on: https://yakihonne.com/article/naddr1qq2j6uzfg9jz63m2xe5x64zgguekxkfn2pnhzq3qu6qhg5ucu3xza4nlz94q90y720tr6l09avnq8y3yfp5qrv9v8susxpqqqp65wmf7h76

What rhymes with lol?

You are hilarious!

Soapbox is what brought me to activity pub, and your blog post about mostr is what brought me to nostr. It’s your fault. I’m also vegan btw, but you’ll never hear me say that again. Lol.

You were my first follow, and a regular source of humor for me. Thanks for all you do, Alex.

Here’s one.

Post from WP to nostr.

https://wordpress.org/plugins/nostrtium/

#dearnostr

Since discovering this small, mostly niche, and yet surprisingly welcoming online community, I have been blessed to be part of many wonderful conversations. Most of the people I’ve “met” on this network could prolly be dear friends of mine IRL. I like to believe this will be the case some day, and am open to the possibility of paving that path with any of y’all beautiful people.

Last week a dear friend of mine passed suddenly. Not the first time, but this certainly was the most painful and deep heartbreak from having lost a loved one. Maybe as I grow older and more accustom to this feeling it will hurt less. Maybe it will hurt more. I don’t know. But either way, my biggest take away today (cliche or not) is this:

Life is too short to go about wishing (or being afraid) to have made new friends. Most of us yearn, yet so few of us really try. All y’all who are wondering if true friendships can be made online, why not go ahead and give it a try.

Reach out and touch someone’s heart today. You might be pleased with the result.

Hard to tell what is a cop out and what is desperate clinging to forgotten principles.

Wait. Lemme pick my jaw off the floor.

Call me bonkers, but I’m reminded of a convo I just had with nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft and nostr:npub1kuc70777tsvj67fl75s2dmy376t97hv05xmyuyshzzy6vhj5q5jstv0eyw

nostr:note18kjsq7nd3vwrnw4fh0f5yzy6k9yh796g7mdr7cn4n326a2u2pgxsy4fsch

FWIW I think an “in device relay” is a great idea. I also see the problem with having “multiple” apps to dl, when multiple clients are already a head scratcher.

For “most” people the value prop of a “signer” app will be as an “identity manager” for accessing the entire nostr ecosystem (native apps and PWAs). Given this use case, having “personal storage” built into the actual signer app makes total sense. Il even raise the ante, and go so far as to suggest this app (the “identity manager” class of apps) could even act as a nostr on-ramp for profile building, client discovery, and relay management.

Maybe on paper these are separate NIPs, but in practice a single “this is me on nostr” app wd be bomb!

Wonder what Dries @npub176xpl3dl0agjt7vjeccw6v5grlx8f9mhc75aazwvvqfjvq5al8uszj5asu wd think of my proposal of a more open architecture for content types (and possibly other “types”) in Nostr?

https://yakihonne.com/article/naddr1qq257drt244x6ufkx3xyzs6kdpuh5n3jg459qq3qmanlnflyzyjhgh970t8mmngrdytcp3jrmaa66u846ggg7t20cgqqxpqqqp65w7gtxrh

nostr:note1z2ax604evtxahsahgz85z5a8ykggqgeaknnex8tv67rntywsuzhsszpj2e

True.

A formalized approach for clients and relays to design, test, and publish novel content types for end user needs. It’s a rough start.

Decentralized compatibility is “baked in” to the design, by implementing a bidirectional “handshake” for clients and relays to be learn about and adapt to each others capabilities.

https://github.com/nostr-protocol/nips/issues/862

Oh Snap!

nostr:note1e6kvv3qc3j7m38zf0ze8hpczd3rhvdk8pp7aew3rv6eaaptw0cyq0pyx7w

I know it’s a big ask … and I’m a nostr nobody… but I really think so many event kinds (only for user generated content) will unnecessarily contribute to NIP bloat. And why should new content types be locked behind a NIP approval process anyway?

As a Kind 1 event, this problem could be solved simply by adding a ‘c’ tag. It is a perfect use case for

https://yakihonne.com/article/naddr1qq257drt244x6ufkx3xyzs6kdpuh5n3jg459qq3qmanlnflyzyjhgh970t8mmngrdytcp3jrmaa66u846ggg7t20cgqqxpqqqp65w7gtxrh

Where can I get a TestFlight redemption code?

Nostur is killing it on IOS! nostr:note1kny2z8p3kmg0aqgspajmszjsdctqxtupcm64luy3gzd3nh9qufwquww75f

Sorry to miss that.

I proposed this to nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn a few days ago (via DM). Wasn’t sure if I was way out the window, being a nostr noob myself. But this may be the future for nostr, and (I think) we are both keen on seeing (something similar to) this built out in coracle (and other clients).

—-

I slept on this (as I do) and assembled some pieces in my dream.

Right now bunker has two parts : “bunker-host” and “bunker-admin”, where the former is what stores encrypted keys and the latter is the admin UI for putting keys into storage and managing their shared npubs.

Last night I dreamed of a slightly different architecture, one that plays better with relays and clients.

Seeing as (right now) any bunker-admin instance can manage any bunker-host, it seems to fit that clients could have a bunker-admin embedded into them. But as it stands, bunker-admin (for multiple key storage) is tied to an npub, for which a user must ALREADY have the nsec (plugged into a browser extension). This is NOT the bunker-admin that would be embedded into a client.

Anybody (including an already “trusted” relay operator) can spin up an instance of bunker-host, and use any bunker-admin to manage the keys stored there. (If I understand this right) these keys are E2E encrypted (by password) as soon as the user submits one from the browser. This means that the bunker-host has no access to the actual key data. It’s “warm” storage. So we improve this flow for integration by relay operators, and BAM new users get a “nostr name”, online notes storage, and a “warm” place to hide their private key at the “home relay” of their choosing. (As long as they have their private key in “cold storage”, they are free to “move” their home to another relay.)

But the clients have a major role to facilitate this. The clients’ role (beyond helping users to “discover” home relays) is to provide a consistent (across clients) UX for the creation of nostr names and keys. This would be a “lighter” instance of bunker-admin for end users only (let’s call this bunker-my-admin) that would ALSO plug into the bunker-host (at a chosen domain).

The bunker-my-admin provides for choosing a username and a password, and INFORMING the end user of their keys and how they are stored. It also facilitates end users to log into any client with said usernamenostr:npub1jxh2kga4ve8d4ftahcqtqswvk5z5f7ya0k2kx3dm679hmw4ysesqvt62rj.domain and password (and to look up the FIRST suggested relay in their well-known/nostr.json if nostr:npub1jxh2kga4ve8d4ftahcqtqswvk5z5f7ya0k2kx3dm679hmw4ysesqvt62rj.domain is not a bunker-host)

This (mostly) uses nsecbunker “out of the box”. The only thing further to develop (aside from bunker bug fixes and existing feature requests) would be an API for a bunker-my-admin to connect to a bunker-host (via U+P or as new user) at a given domain and a client implementation of a bunker-my-admin UI.

Am I off my rocker?

Thanks for reading.