Any good documentation to feed a hungry bot?

What’s the best way to filter out long form spam from an article reader? I don’t want to use wot because it’s supposed to be a discovery service but there’s a lot of garbage spam. I could hardcode it but that feels wrong and might false flag good content

WoT alone = FY newcomers and nyms with money

Custom WYSIWYG editor icons :Check:

Whoohoo, congrats!!!

this is why i'm prompting you to think about what you think a helpful API for your task would look like, because after i'm done making the basic replacement for filter search and HTTP for everything else using nip-98 and optionally JWT, this is the kind of thing i can see becoming useful

right now, #realy is a bit messy in the sense that things are all still a bit jammed together in ways that they shouldn't be, and some things are separated and replicating things in ways they shouldn't be

the ideal situation is where you can define a simple single source file that specifies what parts are available, so eg, we have a standard NIP-01 implementation, and added to that is a spider that farms the whole nostr network for this data, and then it exposes protected endpoints that yield search results that precisely fit the needs of vertex

so, yeah, from what you are describing, right off the top of my head i can picture something like an endpoint called `/directory` which takes a parameter of the last-updated-timestamp that you are interested in (as your database already has everything to that moment) and it spews back all of the event kinds newer than that in one big shebang and that funnels into your graph generation pipeline

no, it's just an API detail

instead of returning events, the filter and fulltext search endpoints are specced to return simple lists of events in whatever expected sort order (i'm thinking to put the since/until/sort as parameters to the endpoint, because currently they are by default ascending order, which people may not want, in theory they could even be further sorted by npub, or kind

the reason for changing the API to only return event IDs is that pushes the query state problem for pagination back on the client, the relay doesn't need to additionally keep track of the state of recent history of queries to enable pagination, and i don't like that shit anyway because it inherently is inconsistent, as in, the query could return more events at any moment afterwards, so what do we do if we push pagination on the relay? do we make it update those things? then the client will get out of sync as well

implicitly any query with a filter that has no "until" on it searches until a specific moment in time, the time at which the relay receives the query, and the identical query 10 seconds later could have more events at least in the space since that time, not to mention it may get older events that match pushed to it by spiders or whatever in between

so, i say, fuck this complication, you just make an index on event IDs to event serials and then you search the indexes created by the filter fields, and then find the event ID table and pull every one of those out, and return them sorted in either ascending or descending order that they were stored on the relay (which is mostly actual chronological order)

idk, maybe i should add a timestamp to that index so this invariant can be enforced

anyway, i'm interested to hear other opinions about why the relay should implement filter api differently than i described, but i have thought a lot about it and i'm leaning very much towards returning IDs so the client manages their cache state instead of pushing that on the relay to give people their precious pagination

i already got too much complexity in here

nip-01 protocol is a mess that literally mashes 3 query APIs into one, incoherently

fetch events by id

search events by filter

search events by content keyword search

it's three API methods that are not clearly separated and this confusion is very obvious at least between the "ids" field and the rest except the "search" field

can we combine SEARCH and FILTER together? maybe yes, but that's a separate logic, and it is actually doable with a small enough result set out of the filter before you do a full text contains search

the nip-01 protocol was not designed as a proper API, and we aren't going to progress this protocol's capabilities without adopting age old "API" semantics

smarter relays are the key

idk why they made up this DVM thing, it's just a fucking relay

is nostr's huge data consumption a solvable problem?

Salmon toast

> IF YOU LIKE SOMETHING YOU CAN JUST ASK THE PEOPLE BEHIND IT AND TALK ABOUT THE PRICE.

hmm.

Esatto ma non vale... Sei italiano 😂

Good job!

Question: Are you providing any kind of proofs client apps can easily check to be more certain that Vertex is not lying?

Or even better: with the request one could add some params as to how or what kind of proofs should be provided by such dvms, depending on use-case.

I might sound vague but you get the point I hope.

Very thoughtful. Is DVM a must?

I love Primal search because it lets me search my own notes .. hope npub.pub has advance search ?

21 replies later we come to agreement

Chachi does

Yes to domain centric design and basic separation of concerns, no to premature optimization and overkill like clean architecture for smaller projects where the boilerplate and indirection make up a lot of the code

Choose names wisely and be clear and consistent. Make code expressive and self documenting.

What made you pursue your project? What problem does it solve? Where did you hear about this problem? How do you know it exists?

I think too many people pay too much attention to aesthetics instead of functionality. The way I see it - the code has a functional purpose, it is meant to do something not to look nice or simple so as long as it does what it is useful to someone it is good.

The refactoring process to make code simpler and nicer has nothing to do with its purpose and is s endless endeavor

I'll try and facilitate and help organise some collaborative working on #GitViaNostr projects. I'll arrange a dev call next week. Let me know if your interested. Thank you to those who have already contributed / expressed interest, I'll be in touch.

SHOULD I STOP SAYING GOOD MORNING?

Added model selection. Now you can use it for free! A few more tweaks and it’s off to packaging. nostr:note12ecz3u5ydkkllzlrfecehpe0vxh3lyt6xhpydjulwned7enatyrsf70tqd

Just updated, I just saw the update you made and it works now!

i do this size of transaction about 2x a week, never had one failure, so this percentage metric is probably not accurate

Italians > Greeks.

well, i mute it, so there's that

WoT calculations need to include muting because it's kinda stronger than follow - follow is "i am interested in reading" where mute is "this user is abusive (probably)" they should at least have equal significance but i'm inclined to suggest that mutes should weigh heavier than follows

seems to me like the key the NFC returns should (nay, must) be encrypted or it's a massive security problem

Although, you know, we don't have as much pressure to monetize, as other teams. And we have religious and philosophical reasons to build this.

This is our rage against the machine.