Nostr View

Mazin @mazin - 9mo

We are going to start transitioning filter.nostr.wine to require NIP-42 AUTH soon. If your client still doesn’t support AUTH - please encourage the developers to add it!

1
2
1

mleku ✝Ⓐ☯︎ @mleku - 9mo

no more draft! no more optional!

1
0
3

Mazin @mazin - 9mo

Yup - it’s time. We launched optional support for NIP-42 in March of last year. I think it’s been long enough.

0
1
1

mleku ✝Ⓐ☯︎ @mleku - 9mo

i can confirm that #nostrudel and #coracle both do

0
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

i've implemented code for client and relay side it's not that difficult

0
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

couldn't these be part of tags?

1
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

it really can be part of tags why are you inventing this stuff that nobody else is going to adopt?

0
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

yes, it's called a TAG TAG tag can be whatever you want it to be, it can have one or multiple fields, the only limit is they have to be converted into strings

0
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

ok so why the extraneous prefix string then, surely it's fine to just add it to the filter keys? you could even add just one, and make them tags then

0
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

so you don't have to search for the events you search for the classifications! you make them and publish them to the database i remember when nostr:nprofile1qyf8wumn8ghj7u3wd4kx26m49ejx2a30qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qpq0npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qwsscer introduced me to the filter system of strfry and i realised that the event motif has uses outside the events that are sent between client and relay, they can be relay internal only, they can be meta-events, as nostr:nprofile1qyf8wumn8ghj7u3wd4kx26m49ejx2a30qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qpq80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsgqvarw is talking about yes, this is a better solution, more scalable and more interoperable

0
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

it can literally be adding them only to your database, with labels, and then you just construct nice keys to iterate for you don't have to share those keys, those keys have collections of references, you just return the events that match the keys as for storage requirements, if you were going to store these indexes already surely you can just change the back end to store them compactly instead of raw JSON, and implement a codec to propagate them as needed? the eventstore i use, golang badger one, has a collection of key generators that enable a huge number of tables that can be searched rapidly for values (events) that a user is searching for... to be honest, it's a bit voodoo for me looking at them, because they are written in a clumsy way and not well documented, but i get the general gist of it, and i intend to understand how they work because i'm working on a project where data stores and fast retrieval matter, and this is really just about indexing

0
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

how is it centralised just because your analyser has an identity? it's still it's opinion surely? it's just an internal data type, which means you don't have to actually format them in JSON format if your back end can do it as raw binary

1
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

also i hate the whole concept and terminology of DVMs there is no insert coin, it's not a vending machine i've seen several things in my time working as a nostr dev that tell me that relay data stores have almost infinite potential and flexibility if you have the imagination

1
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

btw, you run nostr.wine right? it's not responding to my attempts to publish to it, yes you know i'm paid up

0
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

sorry, muddled context here tags in filters not tags in the events your database can have meaning for those built into the relay's database logic, doesn't require you to actually propagate it, so NIP-32 isn't relevant, i was talking about FILTER tags fields not EVENT

0
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

this is for the case of propagating that "opinion" nostr:nprofile1qyf8wumn8ghj7u3wd4kx26m49ejx2a30qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qpq8kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sksrfanak is talking about a proprietary, internal thing that he is charging access to just pointing this out, the tags i mentioned were FILTER tag fields, both filters and events have them, remember?

0
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

i was never unclear that i meant FILTER tags, you just didn't catch it that's something you can easily add to a random new NIP that augments NIP-1 the internal tagging system is internal, it's irrelevant, except that it relates to the clients requesting it, so it's FILTER tags not EVENT tags

0
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

also back to 5/5 relays publishing now tx

0
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

ok, that makes sense but ultimately filters are just a query API and nothing says they cannot extend beyond simple matching if the database can do that this will simplify your code a lot if it's just a small extension of tags instead of the whole REQ, simpler to adopt or reject, or ignore... it won't match, obviously, for relays that don't understand it, i'm not sure what that behaviour is though that is an issue that needs to be figured out then i guess the naive, intuitive sense of it is that filters are queries and thus they need to be more flexible than the data they relate to

0
0
3

mleku ✝Ⓐ☯︎ @mleku - 9mo

your systems are cutting edge bro, i gotta give props and i'm happy to pay

0
0
3
Showing page 1 of 2 pages