Silberengel @Silberengel - 6d
Easy way to get people to store kiddy porn and stuff on your relays tho, isn't it?
mleku the disregarded @mleku - 6d
only if you don't charge for access to it this kind of spam attack is only viable for attackers who don't have to pay for the bytes that are being stored crowdsourced moderation would help with this also... reporting is there for this reason
i haven't even been thinking about paid access exactly but accounting for event data would be important with this i just made a thing that allows users to access via their presence on an npub's follow list, and with this oom-kill bug i've got at the moment just verifying that it was because of the terminal config, but i was planning to add so that the followed npubs follows also get read/write access... then the list becomes actually a list of moderators but this semi-open architecture would entail issues with designated moderators having bad judgement and enabling scumbags, so all npubs event publication needs to have accounting, so, a new table in the DB, with a list of npubs and the size of the event data they have submitted within some time windows to track it over time so later i can impose limits for whatever reason, like the follows follows being rate limited as a collective to contain their data input since it's essentially free access... but it also means, with all of this, that it can be investigated forensically - and even, automatically if there is one of these "free tier" users flooding the relay with data then they can automatically be banned for a period if the ratio of theirs versus average is orders of magnitude hm anyway, yeah, so i'm going to add npub-based event submit counting, and have the event saver log the current volume total the actual time-series of this data can also be derived at some point too, since the relay already has an access time, i should make a created timestamp as well so it stores when the relay first saw the event, and this can then be used to assemble a time series graph
