dreamreal16000=the number of concurrent threads Quest wants.
nevetok, dreamreal: updated 16000.
dreamreal42=the answer to life, the universe, and everything.
nevetok, dreamreal: updated 42.
dreamrealacceptance test=<reply>Acceptance tests are often an integration test that covers multiple architectural boundaries, and covers a system requirement: \"can register a user\" might involve a web page for presentation, a serverside controller for handling data from the web page, and a database for storing the data, along with anything else involved; it covers performance, UX, and UI acceptance too.
nevetok, dreamreal: updated acceptance test.
dreamrealadvice=<reply>Advice outside of context is just dogma - and even WITH context, it's just advice. Follow what works for you. Good luck out there!
nevetok, dreamreal: updated advice.
dreamrealidea
nevetIDEA is one of the "big two" Java IDEs, and probably the most popular of them. Has a free and commercial edition, and has capability to work for many, many, MANY languages. URL: https://jetbrains.com/idea See also: ide and ~eclipse
dreamrealidea.seealso.forget
dreamrealforget idea.seealso
nevetok, forgot seealso on idea.
dreamrealidea.tag=ide
nevetok, dreamreal: updated idea.
dreamrealidea
nevetIDEA is one of the "big two" Java IDEs, and probably the most popular of them. Has a free and commercial edition, and has capability to work for many, many, MANY languages. URL: https://jetbrains.com/idea Tag: ide
dreamrealforget eclipse.seealso
nevetok, forgot seealso on eclipse.
dreamrealeclipse.tag=ide
nevetok, dreamreal: updated eclipse.
dreamrealnetbeans
nevetnetbeans is generally the redheaded stepchild of IDEs for Java, now managed by apache since no-one else was willing to adopt it. Capable but an also-ran. URL: https://netbeans.apache.org/ See also: ide, ~eclipse, and ~idea
dreamrealforget netbeans.seealso
nevetok, forgot seealso on netbeans.
dreamrealnetbeans.tag=ide
nevetok, dreamreal: updated netbeans.
dreamrealide
dreamrealsearch ide
nevetSearch for 'ide' matched: ~acceptance test, ~advice, ~eclipse, ~glot.io, ~idea, ~ideone, ~jwz idea, ~jwz java, ~netbeans, ~pep 3, and ~sowa
dreamrealide=<reply>IDE stands for "Integrated Development Environment," a tool that manages entire development lifecycles and typically provides services like code completion, build invocation, test invocation, debugging, and much, much more.
nevetok, dreamreal: updated ide.
dreamrealide
nevetIDE stands for "Integrated Development Environment," a tool that manages entire development lifecycles and typically provides services like code completion, build invocation, test invocation, debugging, and much, much more.
dreamrealide.tag=ide
nevetok, dreamreal: updated ide.
dreamrealide
nevetIDE stands for "Integrated Development Environment," a tool that manages entire development lifecycles and typically provides services like code completion, build invocation, test invocation, debugging, and much, much more. Tag: ide
dreamrealhmm, need to have a way to searh tags, actually. Hmmmm hmm hrmmm
* dreamreal!~dreamreal@about/java/dreamreal changed the topic to: This is the channel for the development of the software that runs nevet: https://github.com/jottinger/streampack
dreamrealtag ide
nevetFactoids tagged 'ide': ~eclipse, ~ide, ~idea, and ~netbeans
dreamrealso... question. there're two repositories for nevet: one is streampack (see topic) and the other is bytecode.news, which is a ground-up rewrite and redesign. I think my goal has been always to get it working as a ground-up rewrite, then migrate TO streampack... thoughts?
dreamrealbecause there's still stuff in the old nevet code that bytecode doesn't have, of course
dreamrealit's not a 1:1 feature set, although bytecode has features streampack was intended to have
blueyou're mixing milk and meat. port stuff over until streampack/old nevet is obsolete, then delete it
dreamrealnot just obsolete, replaced, then, which is more or less what I'd intended to do
blueyes
blueI wouldn't invest time in merging repos, seems like a timesink to me with little gain
dreamrealas usual, you're a wonderful person who requires only a moderate amount of tolerance
blueI give you the raw unadulterated truth. at the mild cost of current annoyance, you avoid falling on your face later
blueit's also called the min-max principle
blueminimise dumbness, maximise immediate action
dreamrealSure. Yet you also make sure to offer opinion, and the opinion is distracting from the truths.
blueya. just remember that 99% of what humans say are opinions
blue'truth' is just an SEO term we use to make our opinions sound more legitimate to ourselves
bluetake it with a grain of salt
blueespecially MY opinions
dreamrealYet we can always write clearly such that our opinions don't get in the way if we're baseline competent. If.
dreamrealFor example, I could have just decorated that last statement with "and krautrock suxxxx!"
blueyes
bluebut you also made your sentence meaningless, and you knew you would, by adding that if, because that if is all you had to say really
dreamrealOf course! The "if" at the end was a twisting of a knife to illustrate a point.
blueyes. but all you meant to say is that we are for the uttermost part NOT baseline competent. that's the crux of the matter, isn't it
dreamrealonly for people who fail the metric regularly.
bluefair
Chronosdreamreal: Oooh, tags. +100 for tags.
dreamrealTag support has been in since early days, but apparently SOMEONE forgot to search for them specifically. Fixed.
Chronosdreamreal: Side note: Thank you for supporting dark mode.
ChronosMy eyes have always been, shall we say, imperfect. Dark mode is much easier on them.
dreamrealon the sample content site?
dreamrealor my website?
dreamrealblue: thanks for the input, though: it got me to file issues for coverage in bytecode vs streampack (mostly AI features) and gave me a migration path. When I finish getting the certs set up for the domains this weekend, I'll probably do the cutover.
dreamrealChronos: you have blue to thank for that, he pushed me into it
ChronosEither it defaults to dark in general, or it's querying the user preference. Either way, it's dark, which me and my eyes very much appreciate. :)
Chronosblue: Thank you!
ChronosI can tolerate white, but it does hurt my eyes.
dreamrealme too, I just don't design UIs at all so the L&F was very default
ChronosRandom off-topic comment: Every time I scratch at the surface of Go (the programming language), it's so obscenely ugly. I've never seen a language with so many warts and gotchas in my life.
dreamrealPerl noob, eh
blueyw, dreamreal
bluedreamreal: I've finally found a *somewhat* acceptable way to manage separate browser profiles per web app
blueso in the case of discord, I have this:
blue spawn-sh "brave --app=https://discord.com/app --user-data-dir=$HOME/.config/web-apps/discord";
blueit's basically a bespoke browser profile only for discord, and the only thing I've yet to get in order is not rely on the totally buggy bitwarden browser extension, but get accesses directly from a locally installed bw client
dreamrealheh
bluethis is how browsers should be, imho. completely separated contexts per domain. obviously it would make fb & co tracking impossible, but that's a design goal, not a bug
blueit also makes XSS attacks moot: if you're only logged into one website per profile, there's no other profile to be hijacked
blueyou might argue this breaks oauth, but it doesn't *have to*: auth requests can occur in an ephemeral tab that gets destroyed after you auth
bluewebsite -> user clicks "login with gh" -> ephemeral tab opens, you log in, but the context isn't shared with the main window. nor should it be anyway, per oauth
bluethis also solves another problem: whenever I want to oauth with google, I get a side-effect of staying logged in later. but's unintended: I only wanted to have delegated auth to the website
bluedreamreal: substack was hacked, fyi
dreamrealwha? url?
bluewife told me should got an email aobut a notice of a security breach, you should have got one as well
blueshe got*
bluethey claim emails and phone numbers were leaked. I'd consider all data leaked, tbh
dreamrealhaven't gotten one yet, and substack has none of MY information on it; my id on substack is entirely obfuscated
dreamrealthey don't even have my phone number or main email address
blue"Passwords are still possible — users who signed up before 2023 might have one — but in 2026, the user must actively choose to create one"
blueWelp, the confirms the notion that you should never store passwords if you can help it
bluethat*
dreamrealyeah, that's an issue for this app too
blueunless you're an email provider or other source of truth provider, storing passwords not very smart
dreamrealyeah, I want to use oauth or something else, but that's definitely not a strength for me
blueI'd even argue that storing passwords for a secondary, non-source of truth website, has zero benefits
blueit doesn't increase security: people who have access to your source of truth can typically reset passwords
dreamrealI don't think I'd argue against that assertion :D
bluethe only 'downside' of magic links is that there's a bit more friction. but if you stay logged in and your device has a pin/password, it's all good
bluealso technically I'd argue that magic links offer stronger assurances on identity
bluejust knowing a password is weaker than "I have access to this account's source of truth"
dreamrealYeah. MY problem is that I am behind on security design for that surface
bluethat WILL become an issue for you once the frontend gets more focus/attention
dreamrealIt might be good to focus on it before it deploys, then
dreamrealbetter to get it as right as possible before we commit to a published design
Chronosdreamreal: Ha! I've never been a fan of Perl either. I've had to do some minor maintenance on Perl scripts. 2/10. Would not recommend.
blueyes. you could start simple: not full oauth, just magic links. magic links are easy: generate a code with a timestamp, send email to user. user needs to enter code within timestamp. you don't need oauth for that
dreamrealI loved perl back in the day :(
bluethe magic link table is simple, too: id: primary, code: string, created: Date
Chronosblue: I agree that browsers, by default, should be completely separated contexts per domain. Although that'll never happen. :(
blueyou could even use the code as primary since it needs to be unique anyway, but I'd add id for good measure
blueChronos: agreed. there's simply zero incentive to break truly secure web, and with google basically owning the only viable browser stack outside of macworld, AND being an ad provider at the same time, the odds are basically zero they'd push in that direction
dreamrealblue: so what would that do: "to log in, click here, then check your email"?
dreamrealclick the email link, bingo-bango, you're logged in?
bluedreamreal: yes. that's one variant. another one is sending you a (usually six-digit) code per email, that you then need to enter in a 2nd step
dreamrealwhich one's better?
blueI prefer the latter approach, it's a bit more secure since you can tie the frontend session to the sent code
Chronosblue: yep. They even "gave up" on their whole "no third party cookies" things. Which seemed like the minimum they should do
dreamrealHmm, I wonder how that'd be integrated into the auth system
dreamrealcan you file an issue for it?
bluesure
dreamrealthank you
bluebasically the idea is that you're sending a 'password' (short-lived, but still password) per email. that verifies: source of truth (I OWN this email) and matched identity (I am the one who initiated this action)
blueinside the <form> tag, you'd put something like the record's id, from the db
blueadded a small bit about expiry, which I'd forgotten
blueobviously you can choose any other value than 10 minutes, some websites do 20 minutes. I think 10 minutes is good
bluethe higher your desired security level, the lower the cutoff time
bluenote that interestingly, this is *not* a real login workflow: it's an auth workflow, unbeknownst if you have an account or not. it doesn't even need to check if the email address is in the db before proceeding
bluethe check itself can occur postauth, and then you fork on login/account creation
blueChronos: yup. would be really nice though if there were a browser with proper isolation. funnily, modern browsers do *hardware* isolation so that the entire browser doesn't crash if one tab hangs up. but they didn't go the whole nine yards and properly separated contexts
blueseparate*
ChronosDoesn't Slack do that authen-via-email thing?
bluepossibly, it's fairly common today
blueslack is not an ID provider so I'd argue it fits
ChronosI don't know enough about security to know if that's a good idea, or a bad idea, or sometimes a good idea, or sometimes a bad idea, or somewhere in between depending on context, or or or...
blueyou can note this: it's almost always a bad idea to store passwords, as a provider. it has virtually no benefits, and only downsides
blueI like password managers, but they're not systematic. many people don't use them, and use weak passwords. and also reuse them across services
blueif you don't store passwords you eliminate an entire error category
bluesimilar to payment data: that's why you don't store CC details, normally
bluesome websites store like the last 4 digits for verification, but today you'd just store a token from stripe or whatever
blueanything that's sensitive should be stored at its source of truth
bluebanks, email providers, payment providers... those usually have dedicated security team.
blueteams*
Chronosblue: Don't most services store hashes instead of passwords?
dreamrealthey do but that's not really sufficient
ChronosAnd use some combination of user name, salt, and password to generate the hash? Making it harder to brute force the password.
* Chronos isn't a security person, so only knows some high level basics.
dreamrealharder != sufficient
ChronosWhat would be sufficient?
dreamrealfor password storage? It's a moving target, that's the whole problem
dreamrealit used to be a salt+encrypt, but computational increases meant that could be broken
ChronosMy assumption is there is no perfect solution, just good enough solutions.
dreamrealyeah, that's always the problem. Moving to a "hey, we're sending this to a known address for you, YOU verify" moves verification to whatever the email provider uses, and stores nothing useful locally except "they used this one-time pad that's no longer useful, bwahahaha"
dreamrealI guess you could have an exposure surface IF they got a pad generated, scooped the number recorded before it was used, and used it themselves
dreamreali.e., hit the app, export the data, use the data before it expired...
* Chronos is sufficiently unfamiliar with email to know how secure it is these days.
dreamrealemail itself, meh, the providers are responsible for it
ChronosIf I personally ran a website, I'd seriously consider washing my hands of authentication complexity, and using emails for that.
ChronosMost websites have some kind of flow for resetting passwords via email anyway... so...
dreamrealYeh, well, email is sort of a "do you own your identity" thing. My problem is that bytecode should not ever assert ownership of identity; it has password support for users, but right now it's exposed only in HTTP (it has a tiered authentication model). What blue is suggesting moves that password out, in favor of "can you echo a signal we sent to someone we presume is you" which is, indeed, a lot
dreamrealmore securer.
dreamrealIt also has a lot less of a burden for ME, and I'm all for that!
blueChronos: dreamreal is basically on target here. The problem isn't how well protected you store them, the problem is you store them at all. Any attacker could get them and just wait until the technology's around to crack them.
blueit could be long enough that it's irrelevant, the systems/people are already dead, but it could also be tomorrow
* dreamreal!~dreamreal@about/java/dreamreal changed the topic to: This is the channel for the development of the software that runs nevet: https://github.com/jottinger/streampack
dreamreala poem: roses are red/violets are blue/omg that guy reeks
blueChronos: if bytecode should not ever assert ownership of identity, then it may practically not store passwords
bluethose two sentences are effectively the same thing
* dreamreal taps the glass
dreamrealpoem sunsets with indigent cats
neveta poem: Cardboard kingdoms catch the amber light,/While tattered sentries warm their matted fur./The sky spills gold on alleys out of sight—/A feast of color for the ones who were//Once sleek, perhaps, or never knew a lap,/Now stretched on concrete, watching heaven burn./The sun asks nothing, minds no widening gap,/And gives its copper coins at every turn.//They blink at beauty with their knowing eyes,/These scraggly prophets of the dimming street,/As crimson bleeds through all the merchant's lies/And makes, for once, the gutter bittersweet.//The light fades equal on the lost, the least—/One moment's warmth, one democratic feast.
a poem: Cardboard kingdoms catch the amber light,/While tattered sentries warm their matted fur./The sky spills gold on alleys out of sight—/A feast of color for the ones who were//Once sleek, perhaps, or never knew a lap,/Now stretched on concrete, watching heaven burn./The sun asks nothing, minds no widening gap,/And gives its copper coins at every turn.//They blink at beauty with their knowing eyes,/These scraggly prophets of the dimming street,/As crimson bleeds through all the merchant's lies/And makes, for once, the gutter bittersweet.//The light fades equal on the lost, the least—/One moment's warmth, one democratic feast.
nevetAnalysis: This poem is written in iambic pentameter with an ABAB CDCD EFEF GG rhyme scheme, making it a Shakespearean (English) sonnet. The volta occurs at line 9 ("They blink at beauty"), where the focus shifts from describing the scene to reflecting on the democratic nature of sunlight. The formal structure creates poignant contrast with the subject matter—stray cats in urban decay—elevating the marginalized through traditionally elevated poetic form.
bluethe whole 'reset your password via email' thing is a chain of trust, anyway; passwordless logins generalise this concept
bluewhilst getting rid of the footgun which is storing passwords
dreamreala poem: roses are red/violets are blue/omg that guy reeks
nevetAnalysis: This poem is written in free verse with no consistent meter or rhyme scheme (the traditional "red/blue" rhyme is broken by "reeks"). It subverts the classic "Roses are red" quatrain form by replacing the expected romantic or humorous couplet conclusion with a blunt, colloquial observation, creating bathos through the abrupt tonal shift.
* nevet joined #nevet
* dreamreal!~dreamreal@about/java/dreamreal changed the topic to: This is the channel for the development of the software that runs nevet: https://github.com/jottinger/streampack
dreamrealpoem epic potato chips
neveta poem: Golden discs of crispy fate,/Salt-crowned treasures on my plate./Crunching thunder, flavor bold—/Each chip worth its weight in gold.
a poem: Golden discs of crispy fate,/Salt-crowned treasures on my plate./Crunching thunder, flavor bold—/Each chip worth its weight in gold.
nevetAnalysis: This poem is written in iambic tetrameter with an AABB rhyme scheme (fate/plate, bold/gold). It's a quatrain—a four-line stanza—that playfully elevates potato chips through hyperbolic imagery and precise meter.
dreamreala poem: I hope that Chronos/Eats his children/More rarely/Than Saturn Do./WORD.
nevetAnalysis: This free verse poem lacks consistent meter and rhyme scheme. It employs capitalization irregularities and conversational tone ("WORD") while drawing on Greek (Chronos) and Roman (Saturn) mythology - ironically referencing the same deity to create intentional redundancy that undermines its own comparative statement.
bluea poem: Awoke dead. Woke dead. Oke dead. Ke dead. E dead.
nevetAnalysis: This experimental poem uses systematic erosion, removing one letter from the beginning of each line to create a descending visual pattern. It lacks traditional meter and rhyme, employing instead a concrete/visual form that mirrors its theme of gradual dissolution or death through linguistic decay.
* dreamreal giggles
bluehe totally missed the social criticism...
dreamrealOf course. And there are length constraints on the analysis, too. And stop gendering an LLM!
blueyou fool, nevet is a male word in hebrew
dreamreala poem: I hope that I/can eat my pie/While in the sky/But I'm not high
nevetAnalysis: This poem follows an **AAAA rhyme scheme** with consistent end rhymes (I/pie/sky/high). The **meter is iambic dimeter** (two iambic feet per line: "I HOPE / that I"). It's a **quatrain** written in a whimsical, sing-song style reminiscent of nursery rhymes.
dreamrealthe LLM is ungendered though
dreamrealanyway, the chaining works
blueshrug, it's all nevet to me! if I hebrew, he'd say 'he'
dreamrealwhich is the whole point
bluespoke hebrew*
dreamreal*nod* I get it, nevet is male, the llm is not, this is all proxied
dreamrealokay, that means the AI infrastructure works AND the loopback stuff is in place
blueyou know what's also proxied? CONSCIOUSNESS!
dreamrealnow I get to look at the userauth stuff again :/
bluehahahaha
dreamrealThe summarization stuff for channels and urls is actually really important going forward, but userauth is a little more core
dreamrealChronos: the url summary via LLM is actually *huge* and represents an idea I've been working on in one form or another since 2002 :D
dreamrealblue: so... we need to think about the auth a little more, because of REST
bluedreamreal: shouldn't REST be per oauth?
dreamrealI mean... the UIs would use it
blueyou mean the frontends will use rest to communicate with the backend?
dreamrealthey damn well should, yes
dreamrealthey should have no access to the underlying system
blueand in case of auth'd operations, you send the user's jwt token with the request?
dreamrealYeah
bluethat sounds pretty straightforward to me
dreamrealI'm iterating on the issue, will have comments for the issue soon for your review
Chronosdreamreal: Rather than "echo a signal we sent to someone we presume is you," what about emailing users a magic temporary URL?
dreamrealChronos: give me a sec, writing a comment that captures my thinking
dreamrealI don't really like the magic url bit, but it's six of one, half dozen of another, file a comment, that's why it's an issue!
Chronosblue: Yep, that makes sense — I love the idea of not storing passwords at all.
dreamrealMe too
dreamrealblue's nowhere near as stupid as people say! ... just as annoying, though. :D
bluethe annoying bit is a feature, not a bug
dreamrealyeah, that's what you keep saying
Chronosdreamreal: What don't you like about the magic URLs?
Chronoss/magic URLS/magic _temporary_ URLs/
Chronos(I'd give the user ~10 minutes to use the magic temporary URL emailed to them.)
dreamrealWell, the magic url is yet another path for the UI to follow, for one thing
dreamrealMaybe it's nothing, but I don't do UI unless I'm given no other choice, and I will ALWAYS find a way to have another choice because my UI skills don't suck, they blow
dreamrealplus, the magic code path is easier to localize per UI (I am hoping the initial ui deployment has two execution paths)
ChronosMy _instinct_ is that the advantage of a magic temporary URL is that the user doesn't need to take the extra step of copying and pasting something.
dreamrealso I am hoping to have nextjs.bytecode.news and primate.bytecode.news on day one, with www pointing to whichever one is best
dreamrealChronos: yeah, I get it
dreamrealI just think it binds the url to a specific UI
blueConsider this, Chronos. A magic URL is something you could by accident send someone, granting that person full access in your name
blueIt's not inherently a problem, but an avoidable one
ChronosAh. Hmmm. Legitimate reasons.
blueThere's also the ages-old idea that GET should be idempotent. Magic URLs violate that principle. They incur a login.
blue(itempotent and not stateful, that is)
ChronosYou guys have definitely thought this through.
dreamrealI can't say *I* have!
* Chronos chuckles
dreamrealI'm winging ALL of this, man
dreamrealpoem flying by the seat of someone else's pants
neveta poem: Trusting hands I cannot see,/Steering through uncertainty—/Not my grip upon the wheel,/Just faith in what another feels./Blind passenger to their command,/Flying where I cannot land.
a poem: Trusting hands I cannot see,/Steering through uncertainty—/Not my grip upon the wheel,/Just faith in what another feels./Blind passenger to their command,/Flying where I cannot land.
nevetAnalysis: This poem is written in iambic tetrameter (four iambs per line) with an AABBCC rhyme scheme (see/uncertainty, wheel/feels, command/land). It's a short lyric poem consisting of a single sestet that explores themes of trust and surrender through the extended metaphor of being a passenger.
ChronosI like that y'all are discussing this. I get *so exhausted* of all the bikeshedding in software engineering.
blueMagic links are *still* better than passwords: however, I'd consider passwordless auth the gold standard.
ChronosThese days, the words "best practices" make me want to break down and weep unconsolably.
bluewell yeah, best practices is performative nonsense
dreamrealThis is a pretty severe rewrite of the auth module, but ... honestly, with 0 deployments and 0 users, who cares? Let's GET IT AS RIGHT AS WE CAN!
ChronosI think I misused the word bikeshedding above.
dreamrealAnd if there's a good idea out there that damages us little but we have to code? Darn it all to heck, I guess we programmers get to program some
ChronosI think I should have said... something about being a lemming...
dreamrealyakshaving?
dreamrealspherical cow-moulding?
ChronosOne thing I *don't* like about magic links is now you have *two* browser windows.
dreamrealI think I could have this auth code stuff written for the back end by tomorrow
Chronosdreamreal: Regarding getting it right: dreamreal+=1
Chronos^^^ Bug. Karma module should pick that up.
Chronos(Just kidding)
blue"The 202 response is returned whether or not the email exists in the system (prevents account enumeration)" < this is good
dreamrealbut I want to make sure we're doing it right
dreamrealChronos: heh
Chronosdreamreal: How are you handling the sending of emails? Using a third party service?
dreamreal+1 and -1 was thought about - as was the "^^" signal indicating agreement
dreamrealChronos: MTA locally
blue"This means fishing with a fake email is harmless: the OTC record expires in 5 minutes and nothing persists." agreed
dreamrealyou configure which MTA you want to use and it gets used :D
dreamrealand MTA configuration on this thing was a TOTAL pain in the arse, and will always remain so: I expect user interfaces to say "remember to check your spam folder" even though I have dkim set up
blue"Issuing a new code invalidates all previous codes for the same email
blue"
bluethat is stronger than the guarantees I offered, but why not
ChronosHow would email authen handle synonymous emails? Examples being "johndoe@gmail.com" vs. "john.doe@gmail.com", and "johndoe@hotmail.com" vs. "johndoe@outlook.com"?
ChronosThose first two and last two emails are identical.
dreamrealChronos: well... okay, so the way nevet handles users, the email is actually irrelevant
blueChronos: read dreamreal's write-up, I believe it handles that
dreamrealthere's a principal and the principal has related identities
dreamrealon IRC, it uses SASL to validate, and an admin HAS to set that up
dreamrealso I have it set that if I log on to libera as "dreamreal" without sasl, i'm not, like, nevet's concept of dreamreal
blueScheduled cleanup purges expired records
bluebit conflicted about this
bluetechnically, it's ok... why not reuse codes, in theory
dreamrealeach IRC server has its own rules, but I can set it up so I'm authed if I'm dreamreal on libera, but epesh on undernet... is just this guy
blueI guess I'm overthinking this, I don't really care in a 16.7M space
dreamrealhttp authentication is the SAME AS IRC in structure: it's an identity that resolves to a given user principal
blueit does adhere to the idea that the code is time-bound, anyway, so all good
dreamrealChronos: all that to say that IF the system manages to create john.doe and johndoe and johndoe+foo and john.doe+foo for a single user principal... it's noisy but I don't care
Chronosdreamreal: Can you paste a link to your email authen write-up? (It's probably above, but may be hard for me to find... due to eye issues)
ChronosLike, extra double deluxe family size hard.
dreamrealI get it :(
dreamrealso the token stuff we're talking about is for a *specific* service binding, over HTTP
ChronosMy IRC client does a good job helping to distinguish some key things though.
dreamrealIRC, DISCORD, SLACK are all different services and have different binding mechanisms, so this is scoped almost exclusively to HTTP
ChronosOff to eyeball those pages :)
dreamreal(what the ingress adapters do is say "do I know how to map a user to a principal? I do? So let me do that" - discord does not, neither does slack. IRC does, therefore I can admin the bot from here... and console assumes the user principal is always the super-admin.)
dreamrealand for authentication on IRC, it HAS to be MY SASL-authed account with known attributes, so someone would have to snipe my IRC login for real to fake it. And I can always lower my permissions, anyway.
bluedreamreal: ack'd
bluethe addition of the email to the table for rate-limiting is good
dreamrealblue: so the next question for YOU is: how difficult would it be to leverage that mechanism from a UI?
dreamrealI mean, you're one of the people who'd have to use this
dreamrealif the answer is "AGH I'd rather bite off my own neck" then there's a problem
bluehm
bluewell, I'm wondering where is the association in POST /auth/login
blueboth email and code are known
blueshouldn't it rather be id and code?
dreamrealWhich id would that be, though?
dreamrealthe internal userprincipal id?
bluethe uuid (v7) column
Chronos"6 hex digits" — I would like to suggest eight Arabic numerals instead: (1) Less confusion about 1 vs. l, 0 vs. O, etc. (2) All of humanity is familiar with 0-9; not all of humanity if familiar with a-f. (3) It's even more secure than six hexadecimal digits.
dreamrealChronos: arabic! You're talking to two Jews here!
bluelol
Chronoshahahaha :)
* dreamreal scoffs. Arabic numerals. Pfft. We'd be better off using 0-9.
blueI don't disagree with Chronos. you chose a very low cutoff time, 5 minutes. can go with 0-9, too
* dreamreal points to the "comment" button
blue0-9 space would be indeed easier to memorise, in case you're not a copy-paster
ChronosComment incoming!
dreamrealand JUST IN CASE: yes, I know
dreamrealmuch appreciated
dreamrealChronos: ++
nevetChronos now has karma of 2.
dreamrealblue: ++
nevetblue has neutral karma.
dreamrealblue: ++
nevetblue now has karma of 1.
bluethat is stronger than the guarantees I offered, but not continuity
blueugh, wrong message
bluedreamreal: sending the email and code in the 2nd step proves account ownership, but not
bluecontinuity
dreamrealwhat do you mean when you say continuity?
ChronosComment added!
blueonly the user who initiated the process can finalise it, in the same browser tab
bluethat only works if the frontend knows the id
ChronosOK, back to reading the rest...
dreamrealWell... so the *last design* (from my comment) doesn't create an id until an actual token is matched
blueso after step one, you can an entry in the new table, right?
dreamrealI guess we could aggressively create ids, then require the id, an email, AND the token to complete it
blueyou create*
Chronos5 minutes can be a little tight when my Internet or email are slow. 10 minutes suggested.
dreamrealChronos: get good internet, loser!
ChronosWell, happily, mine is crazy good, these days! Fiber ftw!
dreamrealblue: in the design I was thinking, the id is not created until after step 2
blueso let me rephrase this. after step 1, you create an entry in the new table, containing the code, right?
blueid/email/code/create_at <- that row gets created after step 1
dreamrealI guess we could do it earlier but that implies a cleanup of stale accounts (from a "have they ever logged in?" perspective)
bluecreated_id*
blueI'm talking about the new table, not about user accounts
bluethe one_time_code table
dreamrealAh, right, okay, so you're talking abotu an EPHEMERAL id, not one associated with the account itself
dreamreal"this is the id of the login token"
blueyes. I'm talking about the id of the record of the new table (under Database changes, New table:)
blueI'd expect *this* to be returned after step 1, and be reused in step 2
bluealongside the code
dreamrealso the flow is: user hits a login page, which generates a token and the id associated with that token (the row id, basically) and is attached to an email; the email is sent with the TOKEN, user types in the token on the page (which still has the id, and the email, never having had the token) and the backend goes "let me look at this up... yep, you pass, here's your JWT"
dreamrealam I understanding this correctly?
blueyes
bluethe way it's phrased now, it'd be pretty easy to completely automate account creation
bluethis is not necessarily something you want
ChronosLove the passwordless authentication docs.
bluethe id you return to the UI/frontend from the first request, is ephemeral in the sense that the user doesn't even see it. it's basically a nonce
blueit's then mirrored back in step 2, alongside with the code that the user provided
bluethe id says: I used the browser tab that initiated everything, the code says: I am the owner of the email
dreamrealYeah. I like this idea.
bluethe email is basically irrelevant after being used to send the code. in your code, since you want extra throttling/security, you keep in the db. but it needn't be used in step 2 to verify anything, that would be circulatory
blues/in your code/in your case/
dreamrealYeah, the email isn't important internally anyway.
bluewell I suppose it's not entirely irrelevant: it can be used to match the account / prefill the account creation form
dreamrealYeah, but it's just paperwork at that point
blueyep
dreamrealthe nonce is the main driver: "I gave you a secret code here, I emailed the other secret code, make them match, thanks, here's your JWT"
blueyes. the nonce is the "I am here physically", the code is "I know something"
ChronosIt would be nice to be able to change email addresses
dreamrealwell, we will have profile updates, that's captured as PUT /auth/profile
ChronosOh, ok, sounds good
dreamrealchanging email address is probably a downstream concern, actually... or even a "hey, email an admin for this" concern
dreamrealif you can't convince me you're actually the same person at oldemail@foo and newemail@bar, then screw you, create a new account, wanker"
bluedreamreal: since you're storing the email in the table... you don't have to send it in step 2
dreamrealyeah, I know, it's just extra, and you know how much I like being extra
blueyou're already enforcing one code per email, anyway. code uniquely points at email
bluealrighty
Chronosdreamreal: Yeah, I was thinking from the perspective of the user having access to both emails. If the user loses access to their current email, that seems like a support/administration issue.
dreamrealChronos: it causes me great pain, personally, too, because that HAPPENED to me
Chronosdreamreal: How?!
dreamrealnamecheap let a domain expire with a warning that I missed
Chronosoh crap
dreamreal"HEY WELCOME TO OUR SALES THIS MONTH!!!! btw your domain is gonna expire in three weeks and you don't have autorenew and your funds are insufficient anyway good luck"
ChronosI've gotten to the point in my life where I'd prefer to pay for the next 30 years up front.
dreamrealexcept the all caps was in bright flashing neon
dreamrealThe new squatter offered to sell me my domain back for $25k :D
dreamreali was like "WOW enjoy it mate"
Chronosdreamreal: Jesus. What was the domain? If you don't mind sharing.
dreamrealautumncode.com
bluedreamreal: thinking about this in terms of flexibility: how about returning a JWT in step that has a CREATE_ACCOUNT_ONCE privilege?
dreamrealI'm sure you've heard of it quite a lot. It had one page on it, a landing page.
ChronosIt's still for sale :)
dreamrealChronos: yeah, no-one is going to buy it. Ever.
bluethis would allow UIs to show a small screen "you don't have an account yet, would you like to create one" + terms + set your account name etc.
Chronos"Get a price in less than 24 hours" — Yeah, no. If you can't tell me the price up front, go fuck yourself.
Chronos(Talking to GoDaddy, heh)
dreamrealblue: Would we NEED that? I mean, wouldn't that come out of the flow anyway?
dreamrealChronos: Well, I *did* get a price out of them, but it definitely made me laugh
dreamrealbut replacing my email address on services has been a drag
blueI'd like to mentally separate authentication from login. authentication always happens first. if there's already an account, login happens. but if there's no account, I feel there needs to be a conscious "create account" step
dreamrealI told them that haha, my bad, if they wanted to sell it to me for $100/$200 USD, I'd take it as a very expensive lesson learned with no hard feelings, but uh...
Chronosdreamreal: Losing access to my primary email is one of those things I have nightmares about. Literally. I can't imagine how painful it would be to get everything updated.
dreamrealblue: diagram it out! I mean, if there's a good way to go here, I'm for it!
dreamrealChronos: it wasn't my primary, thank God - that's actually on a different service altogether - but yeah
dreamrealblue: remember, on the HTTP auth side *I consider myself a newbie and ignorant*
dreamrealif there's expertise I am *all for* leveraging it
dreamrealif someone works out the right way to go and tells me what I need to do and I can understand/justify it, I'm a-doing it
bluehm, maybe it's too complex and account creation needs to be automated
bluelol, andrew just pooped all over the issue
dreamrealnah, it's fine, we don't shut down conversation about it
dreamrealI mean, he's not wrong, it's just that *I* don't know how to externalize all auth
dreamrealhe may
dreamrealAfter all, from a user stance of bytecode.news, we really don't care what a user identity is - only access rights are affected. The user identity controls what control you have over your data, that's it.
dreamrealIF there's a way to say "oh, google says this is dreamreal@gmail.com" and we have a way to know that, well, that's cool
blueI don't know what he's gonna suggest, but you need ACLs *anyway*. even if you just do auth by google
blueyou're STILL gonna save dreamreal@gmail.com SOMEWHERE
dreamrealThe ACL is already there
bluehe's being ridiculous
dreamrealI dunno about that
dreamrealI'm not sure I know what he's suggesting
blueneither do I
dreamrealso let's do the smart thing and find out!
dreamrealpoem messing around and finding out
neveta poem: Dancing close to edges, testing every line,/Pushing buttons, crossing borders, thinking it'll be fine—/Until consequences whisper, then begin to shout,/That's the ancient rhythm: messing around, finding out.
a poem: Dancing close to edges, testing every line,/Pushing buttons, crossing borders, thinking it'll be fine—/Until consequences whisper, then begin to shout,/That's the ancient rhythm: messing around, finding out.
ChronosFor what it's worth, I *refuse* to authenticate to websites using that weird "Sign in with your Google Account" feature. For some reason, it makes me *deeply* uncomfortable. This may simply be a psychological issue.
nevetAnalysis: This poem is written in rhyming couplets (AABB rhyme scheme) with an anapestic/irregular meter that builds momentum toward each rhyme. The form is a single quatrain with a contemporary, cautionary tone about the consequences of reckless behavior.
ChronosI don't mind giving some websites my email address, but I don't want my accounts magically automagically linked to my Google Account.
blueChronos: ya, as noted about, it's also completely broken. auth-by-email is a simple, secure replacement
dreamreala poem: andrew is a fartknuckle/his hair as white as lard/and every time he speaks his mind/I think 'what a canard.'
nevetAnalysis: This poem is written in ballad meter (alternating iambic tetrameter and trimeter lines) with an ABCB rhyme scheme (lard/canard). It's a quatrain employing humorous invective, using the traditional folk ballad structure to deliver comedic insult.
bluemy point is that dreamwould would need to build some kind of auth flow ANYWAY, even if he just ends up using google oauth
bluethere's no kind of work being 'saved' by andrew's suggestion here, as far as I can tell
dreamrealWell, I have a feeling the gesture is "use oauth" as opposed to "use google oauth" but yeah
dreamrealwell, let's see what he says
bluehe might have misunderstood: passwordless email auth is conceptually the same thing as delegated oauth
blue"why build this at all" is moot. this is the minimum you need to build, anyway (perhaps bar the table)
dreamrealsure. But let's HAVE THE CONVERSATION. Architecture by fiat is doable, but if we can build consensus it's better.
blueright
ChronosPassword-Less Email Authentication (PLEA)
blueya
Chronos(I thought I was being inventive and clever there)
dreamrealworking on infrastructure for sentiment analysis now
blueya I noticed
dreamrealChronos: did you catch my message about the url summary stuff?
blue~sentiment
bluehm, broken
dreamrealnot implemnted yet, I'm coding it NOW
* blue does snail-imitating noises
dreamrealgolly
dreamrealfixing these infrastructure things is gonna be great, esp if some day I can do !summarize https://apache.org/foo/bar/some-news-item and have a draft article put in the admin queue for verification/validation/editing into shape
Chronosdreamreal: No, I missed it
ChronosLooking now
dreamrealsee 14:28
dreamrealassuming EDT, whch is the only REAL timezone that matters, of course
* dreamreal!~dreamreal@about/java/dreamreal changed the topic to: This is the channel for the development of the software that runs nevet: https://github.com/jottinger/streampack
dreamrealsentiment #nevet
nevetError: Sentiment analysis requires ADMIN role
dreamrealgrrr, I AM an admin!
dreamrealI'll need to work on that structure some for auth but I'd rather it fail than assume too broadly, sentiment analysis works from console
Chronosdreamreal: "url summary via LLM" = LLM coming up with those-urls-with-links-like-this?