Show Idle (>14 d.) Chans
← 2022-12-15 | 2022-12-17 → ↓
dulapbot: (asciilifeform) 2022-12-16 cgra: willing to peer up in pest, if any of billymg, jonsykkel, thimbronion, mod6, unpx want. ditto for any other pest-regular not currently on this medium
signpost[asciilifeform]: I'm considering adding some pest-specific commands to deedbot, like coughing up peering details for anyone within my l2. anyone object?
asciilifeform: signpost: what's the win from it, tho, given as still need to pgpgram key ?
signpost[asciilifeform]: the person would've already had to join pest through someone else, but this will at least make a node with static IP easily accessible once on
asciilifeform: signpost: it's what addrcast/prod is for
asciilifeform: this knob already part of pest spec in 0xfb
signpost[asciilifeform]: maybe less relevant for the IP reason then.
signpost[asciilifeform]: deedbot already knows how to gpg-gram so it'd be easy to have it provide peering info itself to those close enough in wot
signpost[asciilifeform]: another option is I make a lever to request direct peering and the caller supplies the peering info
signpost[asciilifeform]: and I hand crank things out of this queue
signpost[asciilifeform]: really just opening the question of what the proper relationship of bots to humans is in pestnet.
asciilifeform: signpost: deedbot dispensing peerings (and generate own keys, etc) for itself to folx in l2 would be a++ imho
asciilifeform: supposing signpost has the cycles to automate
signpost[asciilifeform]: yeah, that's what I was thinking. cool.
signpost[asciilifeform]: (supposedly!) past signpost made it pretty damn easy to introduce new commands, so lessee
signpost[asciilifeform]: another question, how private do we consider the AT to be, if at all?
signpost[asciilifeform]: was considering whether to make a !!at command for deedbot which pastes current table.
asciilifeform: signpost: erry operator answers for self re 'is my ip seekrit'
asciilifeform: currently we paste'em regularly, but per discussion in spec, 'only peers have any biz knowing existence/ip of station' in general
asciilifeform: signpost: imho third parties (incl. l2+) have no biz knowing'em by default, and very little is gained by displaying'em
asciilifeform: ( see also re philosophy. )
asciilifeform: deedbot eating a pgpgram (from someone with key already on file) , signed, with 'please peer me, key=...., at=....' is 1 thing; but arbitrarily sharing ip of erry peer with erry peer -- why ?
asciilifeform favours 'consenting adults' pov where if bot clearly labeled 'i'ma share errything with certain folx who aint your peers when you peer with me' entirely ok; but expects that many wouldn't want to peer with such bot, esp. since not clear what is gained
asciilifeform: the 'i exchanged key with $operator, and he's on the pestnet but his ip changed and nao link broken' scenario is (or oughta be) 100% handled by addrcast/prod.
asciilifeform: ( 'addrcast' is functionally a means for sending an arbitrary msg (currently constrained to 'at' info) to a specific key )
asciilifeform: presumption is that if you give someone a peering key, your station can tell him its reachable addr/port, and vice-versa, so long as you're on same net.
asciilifeform: (but folx whom you did ~not~ give key, have no biz knowing about yer station at all.)
asciilifeform risks belabouring the point, but imho not unimportant.
signpost[asciilifeform]: nah belaboring is entirely worthwhile.
signpost[asciilifeform]: makes sense to me, no need for an !!at command except for bot-operator
lobbes[asciilifeform]: ye, the general philosophy of 'nothing to the stranger' is a boon imo. Beyond just the spec, upholding it in a 'cultural' way I think has merits as well, from what I can gather at least
signpost[asciilifeform]: sure, was discussing who constitutes stranger to a bot.
signpost[asciilifeform]: least-required info is a fine principle tho
phf[asciilifeform]: i think we should give keys to a relay station to anyone registered in wot
signpost[asciilifeform]: phf: registered at all? I was thinking some manner of "good standing" bar. or at least something with which to antispam.
phf[asciilifeform]: yeah, registered at all
phf[asciilifeform]: yeah, but what kind of spam, you have to generate a pgp key, !!register, then !!peer or whatever
phf[asciilifeform]: and if it's about bozos, then you can e.g. add !!unpeer as a public command
phf[asciilifeform]: like a good old !!down
signpost[asciilifeform]: yeah, just thinking there needs to be a way to silence morons, when it comes to that
signpost[asciilifeform]: one option would be that anyone can register, and anyone currently peered with deedbot can !!up which activates their peering.
signpost[asciilifeform]: deedbot says something like "floppyjohnson wishes to join"
signpost[asciilifeform]: !!up floppyjohnson
deedbot[asciilifeform]: You may not !!up yourself.
phf[asciilifeform]: i think the moat should be optional until it becomes a problem. !!up on #t was barrier to entry, because any could just /join #t and then run their mouth (including spam bots). the barrier to entry is already significantly high
signpost[asciilifeform]: that's fair. aren't there currently station impl flaws that allow randos to fill our disk atm though?
signpost[asciilifeform]: all this said, happy to try it
signpost[asciilifeform]: even a web-hole for n00bs
signpost[asciilifeform]: with which to reg key and get peering info
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-12-16#1018606 << yeah, i think that's a valid point, of which i didn't think, because pest.lisp is significantly defensive
bitbot[asciilifeform]: Logged on 2022-12-16 12:09:45 signpost: that's fair. aren't there currently station impl flaws that allow randos to fill our disk atm though?
signpost[asciilifeform]: proper answer's probably "so they shouldn't"
signpost[asciilifeform]: asciilifeform: any problem with trying the proposed n00b hole?
phf[asciilifeform]: yeah, if somebody's going to pen test for us, more power to them
asciilifeform: signpost, phf : imho n00b hole is an a++ thing, so long as the noobs are given strictly what they need to talk into the hole, and nomoar.
asciilifeform: earlier phf proposed a www-based talk hole, similarly
signpost[asciilifeform]: yup, thinking I put a www reg form on deedbot.org that takes key and nick, coughs up peering blob for deedbot station
phf[asciilifeform]: yeah, www-based one requires significantly more work, where's this idea is just a handful of dozen-lines deedbot extensions
phf[asciilifeform]: signpost, do you still have deedbot running on #a?
asciilifeform: ideally would rate-limit the n00b hole (e.g. 10msgs in 10sec or somesuch) but afaik this knob not yet exists in blatta
asciilifeform: phf: deedbot not currently tuned in #a
signpost[asciilifeform]: lemme see if I can easily fix the bug I have with multiple instances running concurrently
signpost[asciilifeform]: but yeah, that'd be pretty easy if so.
asciilifeform hopes to retire 'dulapnet' in favour of a pest portal, once such thing exists
phf[asciilifeform]: another surgical extension would be !!up support, if a newcommer is connected through a single hole, then it's easy to restrict the way the packets travel. "broadcast-text travels from pestnet to newcommer station, but not the other"
asciilifeform: phf: lurkers can simply read a www log tho, imho not much reason to support dedicated lurk-only peerings
awt[asciilifeform] looks forward to the deedbot n00b portal.
phf[asciilifeform]: asciilifeform, i'm thinking how to support this http://logs.bitdash.io/pest/2022-12-16#1018600
bitbot[asciilifeform]: Logged on 2022-12-16 12:06:50 signpost: one option would be that anyone can register, and anyone currently peered with deedbot can !!up which activates their peering.
asciilifeform: phf: a makes sense
phf[asciilifeform]: because you get your peering, you stand up a station, but you don't get any kind of immediate response until somebody does !!up, you're basiclaly fully deactivated. if you have a lurk-only peering, you're on pest net right away without any need for lords' manual operation
asciilifeform suspects that the gymnastics of setting up station / peering w/ deedbot will be sufficient bozo filter for long time. defo need a bw brake to keep some joker from filling disks tho, at least
phf[asciilifeform]: that's why i'm proposing a symmetrical !!peer from outside, !!unpeer from insdie mechanism, which is aligned with how things are implemented right now
asciilifeform also in favour of a 'n00bs peer with deedbot, can talk at 1msg/s until unplugged' tho, in the mean time
asciilifeform: ( and ideally we'll have N such gates, rather than only 1 )
phf[asciilifeform]: i quite like this idea, because you can standup irc deedbot on some random librenode channel, as a kind of pest outpost
lobbes[asciilifeform]: http://logs.bitdash.io/pest/2022-12-16#1018632 << very much agreed re: bozo filtering. Even though I'm not the brightest, with my ~8 years of "pre-loaded context" it still took me about 2 weeks just to stand up a station and understand what it was doing at a "high-level". For a complete n00b, to be able to even grok what t
bitbot[asciilifeform]: Logged on 2022-12-16 12:27:42 asciilifeform[6]: suspects that the gymnastics of setting up station / peering w/ deedbot will be sufficient bozo filter for long time. defo need a bw brake to keep some joker from filling disks tho, at least
lobbes[asciilifeform]: hey are looking at is a moat in itself
phf[asciilifeform]: 􏿽i also i think !!peer and !!unpeer should be re-entrant. flips bozo bit on a record, generates new peering key for use with toilet station. so e.g. if i go on librenode and do !!peer, will get fresh peering key with deedbot only. this way if i want to bootstrap a pest connection, i
phf[asciilifeform]: 􏿽 only need my pgp key, which is right and proper
signpost[asciilifeform]: hm yeah that's pretty cool
asciilifeform suspects that the main n00b barrier atm is the gnarliness of the proto clients, with the irc frontends
phf[asciilifeform]: maybe having it tied to wot is not a bad idea, e.g. l1 for deedbot means that you get essentially full peering no mater what, and is just a mechanism for emergency pest recovery. if you are negrated by many deedbot l1 you can't get peering no matter what. if you're "neurtral", unrated or l2 you get a regular peering key
signpost[asciilifeform]: being able to park tendrils of pestnet in other IRC networks
asciilifeform: ( not to mention the ugh of '1st, get hold of the right python...' etc )
signpost[asciilifeform]: probs jonsykkel's is the most n00b friendly atm
signpost[asciilifeform]: could get pentacle farting out a static build of that easily
signpost[asciilifeform]: and iirc shinohai wrote a pbuild for blatta?
signpost[asciilifeform] needs to fart the pentacle site out soon too, but will do this deedbot noob-outpost thing first
phf[asciilifeform]: "our ease of use strategy is to tie it to a custom hardcore linux build!", strong symbolics vibes
signpost[asciilifeform]: naw I'll sign a static bin and they can curl2sudo like they usually do!
signpost[asciilifeform]: but hey the thing's hermetic, so the hardcore linux would probably build on their turd
asciilifeform ftr not averse to 'gui client with interface of 'slack' or aol etc' if someone magicked such into existence
asciilifeform: ideally static build (to the extent $platform allows such at all) w/ no deps
asciilifeform: ( on crapple, asciilifeform knows static linking to be irrecoverably broken; errywhere else -- still possible )
asciilifeform not optimistic about own approach to gui , needs over9000 time even for elementary functionality, which asciilifeform not presently has.
asciilifeform: but ideally 1 codebase, if at all possible, rather than N
signpost[asciilifeform] not ironically proposing that whatever deps get pulled into pentacle as vpatches
signpost[asciilifeform]: lot of the gruntwork of reliable builds of ??? is done
asciilifeform had begun, some time ago, an ada pestronics proto, but paused, aiming to polish off new spec
signpost[asciilifeform] considers the thing a build env rather than linux distro atm
asciilifeform: signpost: staticity is rather inescapably key to 'gui pestron'. e.g.: if one were to use 'qt', then gotta pick ~which~, and qt4 won't build on 'modern' shitlinuxen, while qt5 pulls in gtk3 which banned in dulapgentoo & friends because dbus etc
asciilifeform: if want crapple gui, then needs either qt, or raw x11ism, or sumbody who actually knows how to crapple gui 'natively'
asciilifeform: ( or -- for completeness -- phf's tk thing, which seemed to work on crapple, but apparently not elsewhere )
signpost[asciilifeform]: would rec just putting a sane interface at that layer as firewall between the clean station impl and the gui hairball
asciilifeform: for mswin, nfi what even needed ( qt worx, or , again, sumbody who knows how to microshit-gui )
asciilifeform: signpost: or. tho promises to be over9000x complicated
signpost[asciilifeform]: as far as the UIs are concerned, there's this thing emitting updates about a tree it cares about.
signpost[asciilifeform]: and a hole to send the thing commands
asciilifeform: in practice, not so easy to split off the gui. e.g. you want a search box for station's logs. and results come from db. how to format'em depends heavily on the guitron
asciilifeform: for that matter, 'send it commands' also somewhat os-specific. ('local sockets' not entirely standard)
asciilifeform: not to mention the ui nightmare of n00b needing to set up 2, rather than 1 , proggy, and make'em talk to 1 anuther
asciilifeform: (is rather that we have atm)
signpost[asciilifeform]: more a question of what libpest public interface would be enough to keep stationdenken from being infiltrated by qtdenken or webshitdenken
signpost[asciilifeform]: not necessary that there's yet another network protocol at this layer. just granting that "UI" will likely get torn up and replaced repeatedly, I'm sure.
signpost[asciilifeform]: probably that process is what elucidates what a libpest oughta be shaped like.
asciilifeform: db is anuther can of worms waiting to be opened. e.g. atm folx using sqlite, but it not supports (afaik) encryption on disk, which imho ideally would exist (enter pw on warmup of pestron)
asciilifeform: ( and imho , to use any kinda db that ~aint~ solidly integrated into pestron, is terrible idea )
asciilifeform: esp. in re noobs
signpost[asciilifeform]: yep nobody's setting up a local postgres for this thing
asciilifeform: the 'separate $proggy into $parts which talk over $protocol' thing -- is 1 of those ideals that seemed appealing in '80s, but today seems to reliably produce barf; witness e.g. tex's attempt to separate the renderer, and where it is today
asciilifeform: ( is still appealing, imho, if somehow could download working standardized parts from that universe where these existed & worked... )
asciilifeform recalls recent thrd re wordpress db backend
signpost[asciilifeform]: was the conclusion that wp wasn't easily separable from mysql?
signpost[asciilifeform]: I ported the thing to postgresql in about a day a while back; dunno where I put the sauces tho, lol
signpost[asciilifeform]: but the principle that pest should take minimal steps to run is 100% correct
asciilifeform: imho a reasonably-achievable standard is 'takes same effort to install as irc client'
phf[asciilifeform]: *same effort to install as mirc
phf[asciilifeform]: come to think of it, early 2000s late 90s windows software was peak usability. mirc, irfanview, "the bat!" mail client, ICQ, winamp
asciilifeform: aaha. grab exe, run.
phf[asciilifeform]: that is within the limits of what the stack and the approach could provide
phf[asciilifeform]: i remember how annoying it was that own built visual basic programs required a DLL. jeez, you had to have one extra DLL!
asciilifeform recalls this !
asciilifeform: was quite aesthetically ugh
asciilifeform experienced a kind of 'inverse' of this ugh when realized that one could write linux proggies w/out any lib linkage, a la msdos, as demo'd in e.g. 'm'
signpost[asciilifeform]: It really whips the llama's ass.
signpost[asciilifeform]: the tone of software was fun back then.
phf[asciilifeform]: i sometimes have those "'member!" moments, when looking at artifacts of old linux, how different pre-corporate linux was. peak hacker culture. i recon linus's "never break ABI" comes from that old school "grew up in 90s with DOS" mentality, more so than it is a unix thing
asciilifeform: it's quite a fortuitous accident that we still have that api ( while it lasts... )
asciilifeform: if were easier to break in a frog-boiling style, would've prolly been already broken long ago.
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-12-16#1018689 << i have a local instance of barksinthewind running on sqlite, enough that if you just click on any of the immediately exposed functionality, it's been a while that i've seen a php warning or sql error.
bitbot[asciilifeform]: Logged on 2022-12-16 13:13:38 signpost: was the conclusion that wp wasn't easily separable from mysql?
phf[asciilifeform]: but i know for a fact it's not a full coverage. in fact there are bits and pieces of wp code (at least hte vintage we're using) that were clearly there since early days, they are gnarly pieces of mysql/old-php that are full blown "i've never programmed before, so here's some spaghetti that i wrote in 98 in perl"
asciilifeform: phf: a++. iirc did take some massage tho
signpost[asciilifeform]: oh sure, it's a mess. just putting a bit of counterpressure on "clean interface between station and UI is impossible thicket"
asciilifeform: defo not impossible.
asciilifeform: merely difficult.
signpost[asciilifeform]: but I'll grant possible premature optimization
phf[asciilifeform]: 􏿽there are e.g. builders for classes of queries that are not fully utilized in admin or themes, and are there for you to put into your theme logic. they are essentially combinatoric mess of "i want all posts in category X, between these dates, with char count greater than". somethin
phf[asciilifeform]: 􏿽g that could be trivially written as sql query, instead wrapped in a sql construction kit
phf[asciilifeform]: deep inside those construction kits you'll suddently have mysql specific functions, or even mysql specific syntax extensions. so .e.g. "list all posts" works, but "list all posts with author X" breaks
bitbot[asciilifeform]: Logged on 2022-12-16 12:57:32 asciilifeform[6]: ( or -- for completeness -- phf's tk thing, which seemed to work on crapple, but apparently not elsewhere )
phf[asciilifeform]: it's tcl, so should be executed in `wish`, that's missing from screenshots
signpost[asciilifeform]: this box is on wayland so xwayland might have even moar fucked dpi situation.
phf[asciilifeform]: hmm, looks fake and gay :(
phf[asciilifeform]: it looks like the button actually got scaled to accomodate some hypothetical scaling, but that didn't translate into font scaling
signpost[asciilifeform]: it's possible I have a use-flag missing over here too
signpost[asciilifeform]: going to keep doing the multi-net deedbot thing a while first.
signpost[asciilifeform]: but yeah, with scaling 20, button even bigger, text still smol
signpost[asciilifeform]: hm truetype use-flag
phf[asciilifeform]: try calling, font create f1 -family Helvetica -size 18, and then passing -font f1 to button and label calls
phf[asciilifeform]: by the looks of it, it's picking up some default fixed width version, i wonder if maybe Xft backend does the right thing™
phf[asciilifeform]: or if you really want to make sure, do fc-list, which is going to give you all your truetype, and then choose some random font from that list, and replace Helvetica, with whatever. e.g. "Nimbus Sans L" or whatever
signpost[asciilifeform]: for science, tried first with truetype on but same commands, still smol.
signpost[asciilifeform]: yep I probably only have neckbeard fonts
phf[asciilifeform]: signpost, the result ought to be anti-aliased, if you have xft and freetype and such enabled.
signpost[asciilifeform]: yup that worked
phf[asciilifeform]: judging by https://github.com/prati0100/git-gui/issues/29 (git gui uses tk) it probably is at least solvabale if one were to systematically explore the issue
phf[asciilifeform]: signpost, worked how? screenshot!
signpost[asciilifeform]: http://trinque.org/wish3.png << looks nice without fiddling scaling over here, just font size
signpost[asciilifeform]: slight pixelation probably due to running in an xwayland window. I can try it on the x11 box (which is also high dpi) later.
phf[asciilifeform]: there you go then
phf[asciilifeform]: i suspect tk actually sets scaling correctly based on display's dpi settings and whatever other x11 voodoo, but chooses bitmap fonts by default that don't scale
asciilifeform tried this on dulap-gentoo, seems to draw a reasonably gigantic 'button'
bitbot[asciilifeform]: Logged on 2022-12-16 14:11:32 signpost: http://trinque.org/wish2.png
asciilifeform wonders whether would work similarly for system menus, scrollbars, text boxen, etc etc
phf[asciilifeform]: almost like something we can test
phf[asciilifeform]: almost like there's a method by which we can systematically explore subjects like that arriving to a stable point of knowledge borne by experience
phf[asciilifeform]: but i've also realized that most likely this stuff all works fine, because git-gui uses tk, which probably makes it the most used tk app in active deployment
phf[asciilifeform]: would be nice if there was something like tk, but without tcl. an open question is e.g. whether python's tkinter calls out directly to widgets via c, or it uses tcl strings
phf[asciilifeform]: cltk spawns a wish subprocess, which theoretically gives you an ability to spawn remote gui (there's code in cltk repo that sets that up, but i haven't tried it yet)
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-12-16#1018755 << to answer my own question, python sets up tcl interpreter and then mostly sends strings back and forth, but there's also helper code for manipulating tcl data directly, https://raw.githubusercontent.com/python/cpython/master/Modules/_tkinter.c
bitbot[asciilifeform]: Logged on 2022-12-16 18:21:41 phf[awt]: would be nice if there was something like tk, but without tcl. an open question is e.g. whether python's tkinter calls out directly to widgets via c, or it uses tcl strings
phf[asciilifeform]: so, basically, suboptimal
phf[asciilifeform]: what we used to call back in the republican days "the whole spitoon"
signpost[asciilifeform]: hm, not sure why dupes, but otherwise.
asciilifeform: http://logs.bitdash.io/pest/2022-12-16#1018756 << aa, asciilifeform was wondering how it worked w/out tcl! neato (tho also strongly suspect it'll feel palpably slow when over9000 elements in gui or mega-text scrolling etc)
bitbot[asciilifeform]: Logged on 2022-12-16 18:23:06 phf[awt]: cltk spawns a wish subprocess, which theoretically gives you an ability to spawn remote gui (there's code in cltk repo that sets that up, but i haven't tried it yet)
asciilifeform: http://logs.bitdash.io/pest/2022-12-16#1018758 << asciilifeform has a possibly perverse reaction when sees item like this (i.e. ~anyffin which he can't read in ~15min or so) : 'there is prolly a commonlisp impl. that weighs less than this! somewhere!'
asciilifeform: ( may even be literally tru -- how much did e.g. 'ecl' weigh? dun recall )
bitbot[asciilifeform]: Logged on 2022-12-16 18:48:00 phf[awt]: http://logs.bitdash.io/pest/2022-12-16#1018755 << to answer my own question, python sets up tcl interpreter and then mostly sends strings back and forth, but there's also helper code for manipulating tcl data directly, https://raw.githubusercontent.com/python/cpython/master/Modules/_
phf[asciilifeform]: !!rate signpost 11 takes it to 11
deedbot[asciilifeform]: (<= 1 (abs rating) 10)
signpost[asciilifeform]: check out that neckbeardian error message
phf[asciilifeform]: that's silly, rating should go to 11
asciilifeform: hm is the help text intended to be different nao? loox to be same as yrs ago
signpost[asciilifeform]: nah, I have just been using that as a sanity check command.
phf[asciilifeform]: !!reputation phf
signpost[asciilifeform]: got the thing happy with being connected to multiple networks
signpost[asciilifeform]: will now update !!register per earlier thread
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-12-16#1018769 << the only test i've ran so far is load a canticle for leibowitz into text widget, annotate all instances of "the" with an onclick event, and put a marker in front of every paragraph. was extremely snappy
bitbot[asciilifeform]: Logged on 2022-12-16 20:54:21 asciilifeform[5]: http://logs.bitdash.io/pest/2022-12-16#1018756 << aa, asciilifeform was wondering how it worked w/out tcl! neato (tho also strongly suspect it'll feel palpably slow when over9000 elements in gui or mega-text scrolling etc)
asciilifeform: phf: pretty neat
phf[asciilifeform]: obviously you probably wouldn't want to do an "online" state, gotta fully populate state and send user events back and forth, and state changes
phf[asciilifeform]: main reason i did the canticle test, is because i want to be able to load significantly large useful portion of log into the gui, so that i don't have to do hacky things with partial updates and such
asciilifeform: phf: speed of update (e.g. replace the 'the's with a lengthy seq of gensyms when clicked) may be worth experiment
asciilifeform: (does it painfully reallocate when the text box updated 'in middle')
asciilifeform: fwiw log is pretty certainly already big enuff that you wouldn't want ~all~ of it loaded into gui at all times
asciilifeform: (would need sumthing like what heathen chats do, e.g. 'slack', monkey with scrollbar mechanics and partial load)
phf[asciilifeform]: asciilifeform, the test was slightly different: updates between markers, because that's how i plan to implement log updates. basically you have two markers s<hash> e<hash>, and then there's a single op lisp side op, (with-hash-update hash (insert-text ...) (insert-newline ...))
asciilifeform: makes sense
phf[asciilifeform]: i haven't tried stresstesting it (millions of updates in a tight loop or whatever), but casual on-event update worked fine
asciilifeform: presumably there's a way to make e.g. 'reply' button appear when hovering over a line
phf[asciilifeform]: asciilifeform, you can't make widgets overlap or hover, you can have events on things though and you can have menu popup
phf[asciilifeform]: but i haven't experimented with that feature yet, so i'm not sure how smooth or clunky it'll be
asciilifeform: also ok imho
← 2022-12-15 | 2022-12-17 → ↑
Random(pest) | Download hourly DB snapshot | Get Source Code