600+ entries in 0.014s
sina: phf: are you about?
sina: I am imagining you shaking the guy who wrote that blog by the shoulders and screaming DO YOU in his face
sina: mircea_popescu: you made me feel better
sina: I have been watching the logs, interesting discussions
sina: anyway, hi and all that
sina: makes me feel, so tired.
sina: I just popped in to complain about this thing and I feel like nobody else I know will understand
sina: mircea_popescu: suggestions on avoiding ad-hoc datatypes? one idea I was thinking was for example rather than ../messages/<msg_hash> file with contents "sender,delivered_by,message", have a directory ../messages/<msg_hash>/sender|delivered_by|message files?
sina: good morning sirs/ladies
sina: fair. possible rejiggings on that tomorrow
sina: rather each privkey has an additional top-of-file line which states either "-available", "-bogus" or the peer name
sina: didn't end up using symlinks
sina: still needs a tad work to make the code a bit easier to read and finish model.delete_peer()
sina: wasn't as bad as I thought it'd be
☟︎ sina: which is currently not implemented anyway
sina: fair. In any case I think I must retain for the purpose of "chaff" feature
sina: if you're an enemy capable of capturing a gossiptron and knowing of the things, why wouldn't you?
sina: in the model you proposed he would be able to anyway right, just by seeing which symlinks are in keys/bogus
sina: elaborate re machine capture?
sina: damn. that would've made my life easier :P
sina: so I guess I do need to store them
sina: oh. I might use them for bogus data sendage though or something
sina: question: do bogus keys actually need to be stored?
sina: mircea_popescu: still around?
sina: mircea_popescu: I am guessing tmsr is not fond of things like JSON or YAML
☟︎ sina: so in lispland you get this kind of native ability to easily export/import primitive datastructures to disk easily
sina: I dunno much about lisp, but I think lisp handles this better in the sense you write state into the "lisp machine" and can flush that entire state out to disk and read it therefrom as well?
☟︎ sina: because I definitely remember in the past thinking thoughts along the lines of "filesystem is a ~btree, rdbms is a ~btree, why am I ~btree on top of ~btree", and reading discussions about this topic on the internet, and feel like I remember *someone* mentioning something about this
sina: one interesting thing is that I thought there would be some databases implemented as flat files, but I can't seem to find any
sina: lack of subject matter expertise
sina: I just doubt I can impl, e.g. transactions as well as sqlite guy
sina: agreed and understood, I am just subtly trying to make the point of "making me implement a shittier sqlite"
sina: sqlite transaction for example protect against this
sina: two assignment attempts might list the same available key
sina: but this introduces potential race condition now?
sina: what you said "wish to find out what key you can assign" is what I meant
sina: no, I want to assign any available key
sina: I dunno about this suggestion. for example if I want to assign an available key, I need to list the keys in /keys, then subtract from that list the list of keys in /keys/assigned and /keys/bogus ?
sina: or implement a chunk of mv/ln in my code
sina: then I either need to shell out to mv/ln
sina: if its a matter of moving a key from keys/available/???.key => keys/assigned/name_of_peer_assigned.key ...or symlinking as you mention
sina: but what about bogus and available keys? keys/available/???.key and keys/bogus/???.key, so the two questions would be, 1. what are they named, 2. how to transition states, e.g. from available to assigned
sina: with the privkey as the contents of the file
sina: for the assigned keys, it seems fine to have a directory like key/name_of_peer_assigned.key
sina: so there are 3 "states" for a key, 1. available, 2. bogus, 3. assigned
sina: cool, appreciated. so I currently have 3 tables: keys, peers, messages. let's start with keys I guess.
sina: mircea_popescu: do you have 5-10m to discuss the filesystem thing re gossipthing
sina: for now it's set to clean up anything older than a week every week
sina: not right this second, hold pls
sina: quite happy with it
sina: alright, now back to my /tmp dir to try and prototype a fs based thing
sina: looks like this now: 2017-07-08 05:54:50|delivered_by:*local|sender:sina|hello world
sina: fair. names are limited currently to [a-zA-Z0-9_]+
sina: mircea_popescu: "self" just signifies the message was published into the local messages list by the local client itself. suggestions are open for other ways to signify same, e.g. if you think the entry should simply be blank
sina: ok going out again, will consider some more, but I do wonder
sina: I mean, all data is unicode AFAIK
sina: and you contend the actual final implementation of such a thing will actually be less lines of a code than the existing thing
☟︎ sina: mircea_popescu: I guess the gist of the question is really, how is implementing my own btree different at all to using the pretty much identical thing in sqlite
sina: assignments file format = ??
sina: although I don't get that either now that I think about it, how does the "assignments" file know which key is which?
sina: how does that related at all to the "make file with keys"
sina: mircea_popescu: but still even in that case I need to "walk" the list of assignments, looking for ^available, so I need to use grep or write a iterating-finder-thingo myself and then something like sed to change the line or write a text-changer-at-a-line myself
sina: ok true, I didn't think of that
sina: imagine flatfile example of "assigning" generated key from "available" => "user" state, or "user" => "bogus" state, that's moving a keyfile from gossipd/keys/available to gossipd/keys/users/foo or similar action, now my program has to either invoke "mv" or write mv-like functionality into my app
sina: and now if I want to do it in flatfile, gossipd code becomes gossipd + "sinas shitty db-less attempt"
sina: otherwise, how update functionality like "last seen", or "fetch X messages since last seen"
sina:
http://btcbase.org/log/2017-07-08#1680437 << why I used a db: because the spec said use flatfile, I first tried to implement flatfile one and after realising I would need to either shell out to utilities like "touch" and/or "find"/"ls" etc, or implement some of their functionality myself, I decided to import a library that does that stuff not terribly, called sqlite
☝︎ sina: did you make a lispy one go faster?
☟︎ sina: I return, temporarily
sina: trolling asciilifeform best done in lang like javascript
sina: anyhooz, gentlemanz, off for some dumplings
sina: I don't want to carve the stone first time