DDoS

@anthonyfabrizi (A) if you have a .last on a user graph only they can update it. (B) if this is "shared" across users, I guess immutability helps but its just as easy to "hack" and add an item to an immutable table as it is to "hack" and update the .last public property, so same diff?

(C) you can combine this, have your "reading user" know the "chat room user list" and still check .last update was signed by somebody from that list, not an outsider, in which case... even if somebody hacks you can just reject/ignore it.

if you're really cool, could even have a nifty extension/adapter that re-saves the previous valid/legit value back to .last upon receiving any attacker's update, so then they have to "battle back" (even tho they are never shown in the UI) as an extra dis-incentive

this is super cool and publicly happens transparently with @go1dfish 's notabug

you can see some script kiddie discover NAB

then be like "oh I'll just hack the PoW upvotes with a bot"

and on random days you'll see bots attack the network, generating hundreds/thousands of anonymously signed upvotes or downvotes

but then a day or so later, after they feel like they've smuggly proven that nobody would ever use such a "vulnerable" system they... move onto their next project

but if any of these bots persist, its easy to write a counter-bot

and it is as cheap as the script kiddie's bot to run too

now ultimately over time that'd just clog the pipes

so one way I hope to formalize this into the protocol as a spec is for any public gun data (non user-graph)

to have a built in "wikipedia conflict debounce"

where if a particular record is getting DDoSed

all the relay peers (including browsers) have standardized around a type of human-legible lock out period

I'm thinking 15s

so if ANYBODY writes to it within 15s it... trying to "overwrite" the previous person's political view

if they do it "too soon"

they actually lock themselves/others out

and the current free-speech thing they hate stays as the current value

but if they time it right, at the 15 second mark, it'd flip to the "ebay sniper"

so for a human facing app... basically every 15 seconds you'd see the content "glitch" into the next tribe's view and if the teams keep bot battling each other, it'd just bounce back and forth every 15 seconds.

this discourages doing any real network activity during each interval, clearing up the network to handle.... the rest of life.

what's fun is that this is a "dampening" equation that is actually very similar to how NTS clock sync works AND how real life atoms/molecules handle collision.

It takes increasingly larger energy levels (photon emissions) to get faster/preciser bonds

to a point where you can actually bond photons (entanglement) if you can maintain an active connection between them.

but that takes constant energy

however most molecules/etc. come to a resting state

and so they then "cluster" or "fit" into the larger structure in a particular space without being in constant conflict.

thus entropy, dilution, heat loss (energy dispersion), etc. !

this is why in Einsteinian models time & space are the "same thing"

its also why in computer science, compute & storage are the "same thing"

a Turing machine can interchange between them

if you have a lot of space, you can do compute/time operations faster by indexing the information in its "own place" (like molecules fitting into a larger structure) that you can lookup quickly

however if 2 parties are fighting over controlling/winning the same wikipedia paragraph... well that takes a lot of energy/time to force.

as soon as either party gives up... backs off... etc.

then the "heat" disperses