nostr:nprofile1qqsqxefne258ydmfgm2wfl02fsdqgs0d5wx29kweg9amxcqxew4t7kqpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7mn0wd68ytn00p68ytnyv4mz7tjlpwg has talked us into self-hosting OneDev, but we're going to keep mirroring on GitHub, so that we don't get banned from Nostr development. 🫤
Discussion
We use a fork of nostr:nprofile1qqs2qzx779ted7af5rt04vzw3l2hpzfgtk0a2pw6t2plaz4d2734vngpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7hycrvd GitWorkshop for our webpage, by the way. That's a neat dev-hack.
(Please excuse our fight with the site certificate monster.)
Hopefully fixing that today!
OneDev is such a sweet tool although they removed SQLServer support last week which is a big sad for me.
sql = gay
Yeah, unless you want to query a large dataset.
like an event database? using standard nip-01 filters?
that's like using a $10000 CNC machine to sharpen a knife
Vector embeddings.
if you are gonna use SQL, why would you only implement nip-01 filters and not add full text searching?
and it's very easy to add full text indexing with SQL databases, to make it even more fancy
the point of simple filter queries is to make the relays lighter and faster
but i get why there's some value in more than that... full text search would be realllly useful, as would being able to create arbitrary queries like "has a OR b AND c" which you can't do with filters either, or even "a OR b OR c AND NOT d" such as "don't send me events from asshats on my mute list without me having to rewrite the relay to do that"
that's partly why that is already a standard feature on #realy - it doesn't send you messages from people you mute, ever.
I didn't say we aren't going to do more advanced stuff with it.
there is even all these nice vector node points aka "event ID" to use as well
i'd probably spend more time on playing with that if i had more time to spend on playing with things
i already use dgraph's badger, swapping that out to use straight up dgraph would be awesome and easy to do, create a bunch of nodes based on the least common words in posts and link them all up and then throw some zippo fluid on it and flick several matches concurrently
Have you tried out the Alexandria visualization, from nostr:nprofile1qqsdcnxssmxheed3sv4d7n7azggj3xyq6tr799dukrngfsq6emnhcpspz9mhxue69uhkummnw3ezuamfdejj7qgmwaehxw309a6xsetxdaex2um59ehx7um5wgcjucm0d5hsz9nhwden5te0dp5hxapwdehhxarj9ekxzmny9u78m52f?
i muted him ages ago, unmuting now, where?
It'll go nuts and process like crazy, for a minute, but if you wait a minute, it'll show you a graphical view of the publications on thecitadel relay. He needs to fix the zoom, so that it starts zoomed in, and the user has to zoom out, but it's just a PoC.
(I know, our site certificate is expired.)
does it ever stop rearranging it? it's doing a tension optimization right?
just seems to keep on animating even though the state should be steady at some point?
Well, it's never completely static. It reacts when mouse-over and stuff, but it should zoom way in and cool down, eventually.
yeah, obviously it's not right because it didn't stop and my machine isn't a slouch, switch tabs and come back to it a minute later it's still jiggling around, i can't even tell what it's doing, but i think there's basically too many objects in the visualisation and it just would take hours to finally reach a relatively stable state, otherwise it just looks like spaghetti
relational DBs are good at what they do. and until there is a better alternative with good support and ORM that will be my go to. I don't care about the SQL part. I care that sysadmins get to plug whatever DB backend their infrastructure uses into my app and I can still provide good performance.
Databases are infrastructure not part of an application. I'm tired of DBs being hard-coded into an app.
"good performance" from an RDB compared to a special purpose KV store interface is a very fuzzy concept indeed
nothing is ever as fast as what is written specific for a task, unless it has a good compiler and the language is simple enough it doesn't take so much resources it destroys the benefit for JIT (you could make JIT compiled search functions out of sql with go from a reasonably indexed data source that probably would beat any SQL engine)
i find it sad that i have to explain these simple physical laws of computer language processing to people who think they understand how computers work and think that sql is *always* better
no, it's not, it's lazy better, it's not faster better
And I don't think any educated engineer expects an RDB to perform better than a KV, that's the whole point, I don't have a key, I need to query the data within the rows. These basics are taught in 200 level data structures courses that every undergrad in a CS or CPE degree must understand.
In my testing of dotnet, the EF Core framework averaged faster response times at every query I passed to it compared to hand compiled SQL queries for my use cases. Optimized stored procedures were the only performance benefit when requesting rows with primary keys (which is basically never). After the queries are cached in efcore, the performance is as good or better 99% of the time for my use cases, which is also the general consensus around most ORMs. And beyond this caching is used, where cache optimized KV stores blow the doors of KV databases, so I get the best of both.
how would they ban you?
Impossible to talk to anyone without using the NIP repo on GitHub. That's the only place they promptly respond.
Well, except for the ones that don't respond anyplace, of course.