implement a free tier access scheme to help onboarding and discovery

[mleku]

in order to enable a "free tier" of access for realy, there has to be some kind of metric of how much traffic is used

this applies to both reading and writing from the relay

for a free tier, we want to make a non-discriminating, random granting of permission to do all things aside from reading other users DMs and suchlike

for reasons of spam control it may be a good thing to actually keep a database tracking both npub and ip address origins for traffic too

so, probably, this entails creating a new set of record types for the database

[mleku]

it will not block anyone whose npub isn't already on the owners mute lists, and it is not for blocking but rather allowing some amount of access to anyone at all

i'm putting together a specification of what data will be stored.

first point is this only will apply with auth on, and the reason being that i need SOME identifier in the database for keeping track of traffic in and out

second point is the identifier itself will be the truncated hash of the npub and the IP address, whether it's a 32 bit IPv4 or 128 bit IPv6, every single access for a user from a different IP will have a different identifier, and the reason being of course to not presummptively limit access by IP address of origin but by user, per IP address of origin

plus using a digest of this data means that we don't log the actual data of access in the database, although the logs may store that, i have still to fully clean up the logging, for the moment it's heavily logging everything for debugging purposes

anyway...

third point is that it will just keep a running total of all access ever, and the purpose of this is that it can then sum all of these records, and adjust this sum as traffic happens, in order to weight the random selection of non-whitelisted access against all access

so whitelisted users will also have their access accounted for, but this is not for charging purposes, it is to apportion the free tier proportionally against the paid tier, there will be a configuration for a proportion of free requests that will be granted, and the most simple way to do that is to compare the access amount to the total and weight their chances of permission based on their distance from the mean

my goal here is to create an open part to the system so that it can be leaky and permit onboarding while at the same time incentivising paid memberships to relays, and also, kinda as an incentive for client devs to make sure they implement auth and outbox model so this data percolates across the network when nodes have this free tier logic in them

ultimately, the point is mainly to give some space to free use and free access while keeping a cap on it, and helping nostr stay decentralized

[npub1337]

I'm sorry, I deleted the comment that asked the question because I saw your note on nostr and was going to ask there

[mleku]

no problem

i'm also refining the existing scheme, there is now a flag to enable including follows follows in the whitelisted access, i think it should be configurable like this, makes a separate list and checks both but if it's not enabled it's not populated

going to commit what i have got, it builds ok and runs ok, was not really a big hard change

[mleku]

i've decided that this is more complicated... not really sure how to compute things but...

• a counter for the amount of storage and volume of whitelisted users, of the whitelisted users follows, and the non-whitelisted users is a starting point, no need to count them individually

• not really sure, should this be a statistical average? how do i cut up the time windows, if i use an EMA or similar

• a priority queue that favors registered user's requests, so this means more logic in the subscription and websocket handler code that keeps a metric of open connections for new connections to be prioritised on

i'm going to let this one stew for a while and work on other stuff that is more pressing