notedeck column configurations will be stored in nostr notes so you can load them anywhere
by default these will be encrypted/private, but it would be cool if there was an option to make your decks public, so anyone can load your configurations. The columns can be arbitrary nostr filters and perhaps even nostrscripts.
It will be fun to load and browse peoples decks!
What about adding Winamp skinsss 😮
should be very easy to skin notedeck and even share these skins in nostr notes
Holy shit.
Nostr gives you the tools and the freedom to browse as many decks as you'd like. Just don't send a deck to someone without being asked. No one likes unsolicited decks.
NIP-78?
eh thats a bit too general, this may be its own nip so deck-style clients can interoperate better
Have you considered https://github.com/nostr-protocol/nips/pull/1181
i will likely just do something simpler, notedeck currently represents each column as a single filter, not sure what this spec would be for ?
There are common use cases ( like relay-based feeds) that can't be represented with filters. The set operations are complex, but allow for feed composition. DVMs or relays make it open ended, which allows you to avoid unlimited complexity in the spec. Also, breaking each filter key into a separate element makes it easier to build a ui for editing feeds. It's live on dev.coracle.social if you want to play with it.
hmm i am leaning toward wasm filters/reducers for arbitrarily complex local queries:
That works well for local queries or for relays that support map/reduce (which is a good idea), but less well for generic remote relay access, at least in the short term. My approach is to generate efficient queries rather than post process, which is mostly doable.
It seems like regardless of fetching strategy nostrscript and my nip are representing basically the same stuff, so as long as they could be compiled into one another they could be considered equivalent.
Does nostrscript have a spec yet? Until it's more widely available to developers it sort of fails the interoperability test. It's not trivial to write an interpreter for custom feeds either, but it's more accessible since there's no parsing step required.
IMO filters need a negation operation, for at least IDs but authors is easy to see the use of it, and i think almost every other field could use a negation
Thanks! This is what I've wanted/needed to utilize Nostr in the way I do Twitter.
same!
Love it, that's fantastic 🤙
