A real bottom take tbh
Literally the worst parts of my day are anytime I try and figure out where the FUCK something in pleroma source is actually defined.
also friendly reminder that the pubkey field on your relay's nip-11 is in the wrong format, it should be hex, not npub
Iris niggas always seem to be suffering at the whims of the dev. Or maybe the users are just whiny bitches.
Really it's a problem with the people who use it and their expectations. The pack of normies is full of faulty assumptions and bad demands based on them. And then, since there's so very many, it creates a false sense of what they should do. Developers listening to these people cater to the pack of locusts that will ultimately strip their fields bare and then move on to the next one.
POW benchmark for CPU = 28
Sms costs money to send. Quite a bit, iirc. Why would they waste money on free users for insecure (because of sim cloning etc) auth methods? You should always use an OTP generator application on a device you control.
I can't see spam from global feeds, because my desktop client (gossip) does not implement one. It's followed/mentions/replies only, and I must not be an interesting poster to reply to with spam.
Sometimes on my mobile client (nostros) I check the global feed there to make sure my relays are connected up properly, but I mostly do not use global. It's a much much calmer experience this way. Nostr client/relay devs and operators chasing a usable global outside of local only blocklists may be a faustian bargain. If they achieve it, it'll damn the thing a la fediblock. And that's probably a big if to begin with.
ooooo I'm fedposting across the network bridges I'm fedpooooooooosting
Gossip is bretty gud BUT no global and no notifications, just an inbox of posts that mentioned or replied to you. Decent threading, it resolves threads with posts from elsewhere pretty well.
It do be written in rust, if you care about that at all (I care about never having to compile a rust anything but am happy to run the binaries, e.g.)
I don't know who to tag, maybe Gleason.
NDNS - Nostr Domain Name System
A proposal for dns style lookups on nostr, using PoW and existing pubkey verification to establish and verify who owns what name, and where it points
https://github.com/pwm-codes/nips/blob/master/53.md
I feverishly put this together yesterday, a little today and am still trying to flesh out details, but am nearly tapped out for a couple days at least. I'm seeking any ideas as to make it actually work, there are some weak points especially re:propagation and what to do about possible cryptographically valid collisions from pubkeys that are fragmented away from each other. That might actually be a non-issue, but I need to convince myself of that first.
When it's done I'll add it to the relay software I'm working on.
#[0] and/or whoever else stumbles across this.
I am unsure if people can keep quick, punchy posts from falling into memetic shibboleths and banalities. No I will not elaborate, apparently that is bad for nostr.
I think there may need to be some standardization on POW delegation for this to work, as alluded to in the POW NIP for it to not lock mobile users out. Even likes get POW'ed, which I accidentally discovered while I had my POW set to 40. I had to kill the client process, it pegged my CPU
The only tranny free zone left, apparently
> one space before an inline comment
Found the python disrespecter
If I were to respond with the textual representation of a long, drawn out sniff, would the emphasis be placed on the 'i' or the 'f'?
SNIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIFF
or
SNIFFFFFFFFFFFFFFFFFFFFFFFFFFFFF?
Perhaps the dwell is on the 'n' as in
SNNNNNNNNNNNNNNNNNNNNNNNNNNNNNIFF?
Questions, questions.
I will say, for hardcore analytics queries you are going to push up against sqlite limitations quite quickly, as the amount of data you store increases. OLAP workloads (like I assume you plan on doing) don't do well on SQLite (I'm like SQLite's biggest fan). I ran a similar project for a while that did some analytics on a few hundred megs of data in a SQLite database but by the time you start doing big ol window queries etc it really breaks down. I'm talking second to second and a half best case stuff.
If your db grows to any size and/or you really start doing some gnarly queries then I am betting it will want a bigger dbms. You can always start with sqlite though and then port to postgres if your needs grow, sqlite tries to keep its syntax compatible where it can, especially with postgres.