Yes.
But it doesn't mean clients have to reinvent the wheel.
You can just use nostr:nprofile1qqstq4j6pk2sgaupru6l7ah9nq0dueafq356jllwcy7uzlek9yx7hlspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsnpjku2
Discussion
tbh, I was excited at first but it turns out it's too hard to use if you need to create an account with your service for every user.
also, you could consider to make the service free, and allow others to host their version too (if that's not possible yet... or is it?) and then come up with a different way to monetize.
really trying not to sound arrogant. I appreciate the work and think the approach is great. it's a useful idea but the hurdle to start using it and value it brings at the current use of nostr isn't worth it for many use cases imo.
things might have changed, last time I looked into it is a while ago. none of my use cases would've justified paying for it.
fair.
However the free tier will probably last 6 months or so (very generous), and you can always decide the budget you want to allocate. It could be as little as 1$
I think its pretty funny that we’re talking a about decentralized trust metrics and the first solution is a trusted centralized service that computes them? It’s kind of missing the point?
It makes more sense to just compute this locally from contact list you come in contact with.
this approach is fine but it's not going to scale, especially for search. 2 hops network, because of the Dunbar number is going to remain limited to <100k users.
If this is just the “this is why we need indexers” argument then fine, but it would be nice if people actually made indexer protocols with more than one competing implementation so i could actually use them
People can run their own, yes, code is MIT licensed.
My business model is tied to computations, so it's very natural. Making it free would expose me to all kinds of attacks. Accepting ecash is going to happen but the mental burden will always be there.
Perhaps Vertex is more for relays than it is for pure nostr clients (without backends).
as a relay, why should I not self-host it?
good question. I think that over time the cost of self-hosting it will increase in CPU usage and most importantly complexity.
At the moment it uses Redis + SQLite, so you'll have to set up those as well. Also, the service is meant to run 24/7, so interruption in the service will decrease the quality of the results.
this complexity issue is why my relay is completely standalone, and i am also of the opinion that an SQL/NoSQL/GraphQL database is totally not optimized for the simple queries of nostr. so it's not just more complex to set up, and thus more brittle, it's also crappier.
who is going to pay for that?