I get it: something that can inregrate with zap.store for apps, with the browser, with sheetstr for docs, with the filesystem, with ngit, storing settings and configs encryoted on relays, etc.
That kind of integrated experience sounds more like Chromebook (nostrbook) than linux. Which is an interesting fine idea, just not something my boomer mindset would want personally.
You can already login using yubikeys. All you need is to inject another PAM module, no need for a new kernel or a new linux distro.
How you login is just a very small part of the whole and it's already modularized.
Pushstr? 🤔
I am considering moving Amethyst's Push Notification features to a separate app. If that "decentralization" becomes a thing on Nostr, multiple Nostr clients can use just one Push Notification App that keeps downloading of all events citing the user and forwarding to each local client, including the local relay.
When a notification arrives, the Push App pings your preferred Signer app to decrypt it and shows it on the system tray. If you click on the notification, it opens the Nostr event in your preferred Nostr Client for that event.
The good part is that multiple "Push" apps can exist with different ways to address the need for push notifications (using Google Services, NFTY, etc)
Then we would have broken down into Amber (Signer), Citrine (Local Relay), Amethyst (and other clients) and the Push App.
What do you think? nostr:nprofile1qqs827g8dkd07zjvlhh60csytujgd3l9mz7x807xk3fewge7rwlukxgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qgswaehxw309ahx7um5wghx6mmd9usjfpck
Would the Push App be in constant communication with relays?
I'm not worried neithrer, just being realistic.
It would be even better if users were just smarter about their choice of apps so that we don't have to care about what primal does and how that reflects on nostr as a whole.
Primal is representative of the majority of nostr users, hence why the generalization has legs.
We shouldn't shy away or dimiss criticism because it comes from haters. We should remain skeptic, humble and truthful.
Unless you configure relays using IPs, you still need DNS for initial seeding.
This is an issue with every DNS replacement, the bootstrapping requires classic DNS.
Farcaster founder is now going after nostr:nprofile1qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcppemhxue69uhkummn9ekx7mp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz8thwden5te0dehhxarj9e3xjarrda5kuetj9eek7cmfv9kz7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qgewaehxw309aex2mrp0yh8xmn0wf6zuum0vd5kzmp0qyfhwumn8ghj7mmxve3ksctfdch8qatz9uq3samnwvaz7tmjv4kxz7fwvd6hyun9de6zuenedyhszxnhwden5te0vdskx6r9xvh8qunfd4skctnwv46z7a33qqs9xtvrphl7p8qnua0gk9zusft33lqjkqqr7cwkr6g8wusu0lle8jcl7a98v and Nostr. Take it as a complement. He's scared 💀.
He's right in his criticism. You can claim that "oh it's just one client in an open protocol" and that would be a valid counter if that client didn't happen to be the most popular one by a huge margin.
That's a very low bar and besides the point.
Fixes nostr:nevent1qqsgy6n23dwdyqs894ax2tq2ug2hwcvwu9na9hp0gkc3972re7wwfxcn7cxml
Is there a native ngit way to mark that "this proposal fixes this issue"?
I want my own slave web dev that just implements my ideas so that I don't ever have to touch or look at a single line of javascript or css.
Can we bring slavery back just for this?
This is the right move, the P in NIP stands for Possibilities, you don't need a merge 😉
This is the one lottery I can get behind!