that is now done, so the more insistent and persistent the pest is, the more vigorous the response.

note that this also will mean that users using clients that don't do auth with outbox will effectively be permabanned until they use a client that doesn't.

and so it should be.

i pay for my relay to run. i'm paying for their stupidity. not anymore.

you asked if it's true

the answer, is it's true to the extent that they have good, current images of the locations, and how frequently they are updated as the landscape changes

it is now deployed and the latest tag on https://orly.dev now has this functionality.

was driving me nuts for the last few weeks watching blastr type servers keep on doing it.

i'm gonna get the agent to escalate the ban time by double every time also.

they are normalizing the idea of constant universal recording of everything.

their ability to do it does increase over time, and will accelerate as the storage cost is reduced to updating recognition models of LLMs but at some point enough people will feel that glare of the panopticon and start to passively resist it in dozens of ways. one being, to no longer publish photographs.

acquiring the capacity to recognise and appropriately respond to abusive behaviour is a process that requires the individual to go through. it cannot be solved by an authority.

it is sad but the more aggressive and pervasive this kind of abuse becomes, the more the trunk of the stem of the disease of fiat culture is chipped away.

one person at a time, wakes up, and they tell their friends, and then more of that network continues to be attacked and they have a breadcrumb to follow towards the escape hatch.

they are just creating a patch for the consequences of a patch, for the consequences of a patch, for actions of a small group of psychotic megalomaniacs.

eventually there will be no patient, only bandages, and at that point, the system collapses.

i'm inclined to make it double every time they do it sequentially, but i think it cuts back the noise enough just to auto-ban them for 10 minutes.

my relay's shiny performance properties would be depleted by serving these assholes requests and that's a bad thing for anyone providing this as a service for pay

i loved how quickly i was able to implement that. was driving me nuts looking at this shit.

i figured that probably underlying libraries being used by these jerks probably even recognise when the peer keeps dropping connections that they back off.

the log shows that this worked.

it didn't think to extend it to the websocket message reader tho. this means the socket would remain open and they would be able to keep doing it without having to go through the websocket upgrade process.

adding this now so that the websocket protocol immediately drops the connection of an IP that has 3 times attempted event publish without authing when required.

for the HTTP API it will not block requests because they are one at a time, read events will not be blocked, only writing events for the 10 minute

processing events costs compute and database queries. this reduces that load, for auth disrespectoors.

because fuck them. they are braindead jerkwads.

ha, nice, the agent even picked out the nice common "three strikes" rule automatically even though i didn't specify it.

i'm getting a bit tired of stupid relay bouncers that keep on submitting events to my relays without authing, and then just keep on doing it no matter that they are getting blocked: auth required messages.

so i'm employing my LLM coding agent to spin me up a temp ban system so that it blacklists an IP address for 10 minutes after it repeatedly attempts to publish event without paying attention to the response.

hopefully the agent will not make a total hash of this and with a small bit of checking i will have it implemented.

if your fucking event publish script doesn't stop trying to publish when it gets responses, you are an asshole, and the default standard response to assholes is shunning.

10 minutes is long enough to cut the traffic level down. you will just get "connection reset by peer" or some similar message over and over again in your fucking logs, if you fucking even use logs, you assholes, and my logs won't be spammed with constant bullshit.

i forgot to mention:

public-readable relays do allow npub mode reading. but obviously, you can't author events without signing them.

that's the other part of the formula.

i developed this after a lot of thinking about the onboarding problem and the spam problem. this is the simple solution i came up with and it's implemented on https://orly.dev relay which is running at wss://realy.mleku.dev

eventually the problem has to be solved and i'm quite sure that second degree follow list is the perfect solution because you essentially can then permit other users to reply and post to your relays, that implement this, transparently, without any further action but "follow".

it also solves the onboarding problem for new users, all they need is for one user to follow them, and copy their relay list, and they instantly become able to post to those relays.

no other solution i have read about solves this problem, follow packs, free to post relays, this "solution" has been the de facto solution up to now but it doesn't allow relay operators to control spam. second degree follow graphs does.

there is a property in common between the need for a single global currency for the internet, which #bitcoin provides, and #nostr - which is the need for a single social network identity.

there will be an eventual convergence on nostr as an identity system because it lacks the limitations of all of the others: transportabliity and the ability to store attestations of other network identities.

the property of bitcoin that has made it the dominant cryptocurrency is called "moneyness" and this stems from a market need for marketability of the commodity that is to be used as money. this is why bitcoin keeps on growing in value and userbase.

the equivalent in an identity system for the internet is the need to be able to identify a singular point at which anyone can go look and see "that's this guy". keybase (RIP) had a scheme for attestation to link network identities together, but it didn't have the self-sovereign identity base for it. so it never took off for this purpose, even though it made it quite easy to do.

what people want to be able to do is just publish one event that says "i'm this user on X, this user on facebook, this user on gmail, this user on protonmail..." and so on. there is only one place on the internet right now where you can do that, where connecting accounts together can be achieved:

nostr.

one thing that i feel is missing from #jumble nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl is follow list management. i had to use coracle to prune my list because it had ballooned to 98, and looking through the list on coracle i found that a lot of them were ded or irrelevant.

i mean, i don't really mind needing to resort to using another app to manage follow lists, just that nowhere in the interface you can even see it let alone edit it.

in case it isn't clear:

nostr becomes the best option for all-in-one-place network identity attestation

ok, but ultimately many protocols don't provide for the ability to store an attestation. github does, but telegram doesn't, for example. and it's a combinatorial problem because how do you keep them all updated across many accounts?

so you have to constrain how wide you throw the net. some can't be verified, others can be.

anyway, fuck pubky. it's unnecessary, and will die like all altcoins eventually die, because network identity shares properties with moneyness.

if the nostr profile event contains all the outbound references to other protocols, teh other protocols can just refer to it and cover all bases.

i'm glad i did it, because i had sent an application to someone already via btcjobs, and they hadn't seen it, so i'm chatting with them today

feels like it probably will be a good fit, will see later today after a chat if i'm suitable. hoping it happens because it's a nostr job

HTTP has a standard for this, the proto prefix:

so you could have telegram://mleku1 and nostr:// and pubky:// etc etc

almost universally, user profiles on almost all web apps and protocols have fields in profiles for other network identities. it should just be a tag list, even:

["U","",""]

almost all secret keys are valid across all curves, also. so it's really just about registering them. all you need is to have fields for them in the profile metadata events

yeah, it's only missing the net around the hat

conversely, people with more moderate balance of short term and long term thinking attract more moderate demanding partners.

i was just thinking about this a lot with regard to the halving cycle of bitcoin and how actually cycles of low and high supply favors those who can think in both time scales.

being able to live today, and prepare for tomorrow at the same time is the best, because the real world goes up and down randomly.

cows are pretty useless at understanding cars, probably double useless when it's dark. gotta be really careful because they will end up on your bonnet and breaking your windshield. i think getting out and shooing them away works, sorta.

kanzan, saberhagen, and a bunch of others, all just troll bitcoiners here for fun. i wish y'alls would stop talking to them

it would just be a router

i can't see it in nostrudel or coracle mleku1 is my telegram

i'm looking for a #job ... 8 years experience #golang programmer, lots of experience with APIs, #cryptography, #bitcoin and #nostr, badgerDB key value store, concurrency, #network and #protocols

i'm open to a temporary contract, full time, anything at all that will get me some more runway for something better if it's not long term.

idk, i kinda suspect some dodgy event on my relay's store, probably should just nuke it and see

yeah, all of them were. bulgaria, serbia, france, spain, italy (heh), germany, austria, mongolia, china, egypt, probably czechs had one at one time too.

really it was just generations of dynastic professional bullshit artist murderer baby eating cunts moving from one place to the next wherever the booty was.

i figured maybe just a lot of people jumped on it at the same time.

the rebalancing is such a handy feature btw. no more worring about the one channel with most of the sats going offline now

#nostrudel has been doing this to me for quite some time now

nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl is my own personal nostr client Jesus. finally someone built a nostr client that actually makes it easy to test relay functionality.

https://jumble.social it has relay global feeds

also, my custom nostr-specific JSON unmarshal function is nearly as fast as a binary decoder for an optimized binary encoding. about 20% slower. it's also the fastest json event decoder in all nostr land.

further, all the relays that use RDBs and NoSQL DBs are automatically indexing all those tags whether you like it or not.

i write database engines from scratch using a KV store, and it's not really that difficult, and the tailoring of the implementation greatly improves performance. i don't think i'm exaggerating when i say that the #orly database engine is the fastest in all of nostr. it uses an engine that is used for a moderately popular graph database called dgraph, and you can't do that shit without highly optimized iteration and log storage strategies.

if primal forks off the main nostr network GOOD

also, fuck primal. their days of big reach are coming to an end with KYC all the things. i don't think that KYC friendly normies will like the content and probably all kinds of bluehairs will complain to google about it and get their listing chopped despite all the bending over and presenting of the fuck hole that they do.

i'm not joking.

kind definititons are very nebulous, some subprotocols use one, with tags (eg kind 1) and others use multiple kinds for a single subprotocol.

indexing all tags is not complicated, that's what hash functions are for.

i was building a db engine that could do it, it wasn't that complicated. kinds, however, are not self describing. neither are single letter tags. it's my biggest disagreement on the design of nostr aside from the use of JSON instead of an email-style line structured sentinel based format. the reason i prefer this type of encoding is a) it's also plain text b) it's self describing and c) it's cheaper to parse it, json's english-style structuring nearly doubles the processing requirement.

#orly #devstr #progressreport

so, i got it done... again the damn configurations, but also in this case i forgot to put in a label in an outer for loop so it actually worked

the replication path is now this:

try the replicas one by one

if success, done

if fail, try another

all of the replicas do the same thing, in addition to not sending to relays that have their key listed in the X-Pubkeys header and voila. 3 replicas, 3 messages, 100% propagation.

if for whatever reason one of the replicas can't connect to one of them but the others can, it will be gotten to.

this will mean that replication can scale at O(1) so message delay of propagation is linear to the number of replicas. which is much better than the previous uncivilised format.

so now ORLY can set up as a cluster or replicator, either option is possible, and two or more relays can now automatically push their new events to the other peers and instantly any subs on the other peers will also get their events. if any of the relays ded, then the message won't get to them but no user would be on them either.

in theory, the main reason for ded replica would be connectivity. but of course it could be bug, but i'll never mind that for now. still more tasks to complete on this one, but mainly just the reverse proxy and the DNS configuration and then writing a configuration system that generates the necessary configurations for a cluster deployment and voila. the world will have high availability ORLY relays that behave almost like a single big relay on a faster connection.

this will be great for censorship resistance since it would be easy for multiple individuals across jurisdictions to use the config tool to set up their own relay identity and then share their address and key to the other members and no single person can be a target for a total takedown.

and yes, it would work as equally with relays at different addresses as it would for a round robin DNS, the difference being that with different geographical locations, users could be selective for the local replica but users in other locations can use their local one... so, optimising local latency while enabling propagation at not too much slower speed.

this will be very useful for business deployments.

i would further add "and am very much in favour of fuck you primal and you snooty little bitches haha payback for being such attention whores"

if the user can enter any relay address they want, including, like is common in japan, simple IP addresses, those bureaucrat's can't compute this, so they are just gonna blanket ban nostr clients from mobile app stores.

if there is no client, there can be no access to relay.

bureaucrats are not programmers. they are firstly thinking only:

people only use mobiles

web apps are already covered by age requirements in many places

policing web apps out of jurisdiction is going to be extremely expensive for a lot less show and bluster than just blocking social apps

if they do decide to start playing that game, their target audience is people who are already using open platforms and may have moderate technical knowledge and off they go to get VPNS and now while the politician appears to have "protected the children" all they have really done is cover up the "problem" and done their victory laps because politicians have tried the great firewall game a few times and it has never been very successful. the campaigns have been very unpopular because only china does this shit. and apparently, children don't use computers.

so, yeah, the whole point of nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h 's OP is about the fact that mobile devs are going to be the first on the chopping block for being locked out of mobile platforms

the digital rights mob will just keep hammering at the alt app systems, and campaigning against the policy decisions of apple and encouraging people to ditch them, which they won't, because they are hypnotized zombies and i wuv my apple bro don't hurt my brain.

politicians are lazy. that's why they are politicians. if they can get a big fluster over anything to appease some squeaky wheel they are gonna do exactly what is demanded, by said squeaky wheels, which are mostly nosy karens who bewieve in pwoteking teh chlirdrens

those karens are dumb as toast and are not going to squeak very much about geeky kids who have figured out the bypass and because the cross jurisdictional shit... honestly, they can only swat the big guys.

that's the point of the commentary. you get big and popular on play store, you are in the crosshairs

if the dumb karens don't see it, it doesn't exist to the politician whose job is about appeasing these tabloid fodder.

that's the culture of evil, the rewriting of history. to fit the bloated sense of worthlessness of the psychopaths who arrange the misery of history to look like they did a good thing.

good people don't want to rewrite history because they want progress to better. only by forgetting the wrongful things of the past can you repeat them. so they maintain this permanent amnesia of culture in order to maintain the appearance of their right to power.

it is the last insult to all who come after.

a good culture would care

we live in a culture of madness and disease. and we should still remember it, if only as a warning to our descendants.