ByteCode.News
RSS
SubmitLog in

Community

Chat Logs

Thursday, February 19, 2026

  1. dreamreal16000=the number of concurrent threads Quest wants.
  2. nevetok, dreamreal: updated 16000.
  3. dreamreal42=the answer to life, the universe, and everything.
  4. nevetok, dreamreal: updated 42.
  5. 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.
  6. nevetok, dreamreal: updated acceptance test.
  7. 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!
  8. nevetok, dreamreal: updated advice.
  9. dreamrealidea
  10. 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
  11. dreamrealidea.seealso.forget
  12. dreamrealforget idea.seealso
  13. nevetok, forgot seealso on idea.
  14. dreamrealidea.tag=ide
  15. nevetok, dreamreal: updated idea.
  16. dreamrealidea
  17. 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
  18. dreamrealforget eclipse.seealso
  19. nevetok, forgot seealso on eclipse.
  20. dreamrealeclipse.tag=ide
  21. nevetok, dreamreal: updated eclipse.
  22. dreamrealnetbeans
  23. 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
  24. dreamrealforget netbeans.seealso
  25. nevetok, forgot seealso on netbeans.
  26. dreamrealnetbeans.tag=ide
  27. nevetok, dreamreal: updated netbeans.
  28. dreamrealide
  29. dreamrealsearch ide
  30. nevetSearch for 'ide' matched: ~acceptance test, ~advice, ~eclipse, ~glot.io, ~idea, ~ideone, ~jwz idea, ~jwz java, ~netbeans, ~pep 3, and ~sowa
  31. 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.
  32. nevetok, dreamreal: updated ide.
  33. dreamrealide
  34. 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.
  35. dreamrealide.tag=ide
  36. nevetok, dreamreal: updated ide.
  37. dreamrealide
  38. 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
  39. dreamrealhmm, need to have a way to searh tags, actually. Hmmmm hmm hrmmm
  40. bot[jottinger/bytecode.news] New issue #60: Add tag-based factoid search operation - https://github.com/jottinger/bytecode.news/issues/60
  41. bot[jottinger/bytecode.news] New PR #61: Adding tag command for factoids - https://github.com/jottinger/bytecode.news/pull/61
  42. * nevet joined #nevet
  43. * 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
  44. dreamrealtag ide
  45. nevetFactoids tagged 'ide': ~eclipse, ~ide, ~idea, and ~netbeans
  46. dreamrealwoot!
  47. bot[jottinger/bytecode.news] New issue #62: Factoid reference prefix (~) is not protocol-aware - https://github.com/jottinger/bytecode.news/issues/62
  48. * dreamreal joined #nevet
  49. * jreicher joined #nevet
  50. * jreicher joined #nevet
  51. 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?
  52. bluedreamreal: wdym with migrate?
  53. bluejust change the name
  54. dreamrealstreampack already exists as a repo
  55. bluecontaining what?
  56. dreamrealthe old nevet code
  57. bluethen just delete it
  58. dreamrealwas thinking: tag, rm -rf, copy, add, commit
  59. bluewhy?
  60. bluewhat advantage in that?
  61. dreamrealbecause there's still stuff in the old nevet code that bytecode doesn't have, of course
  62. dreamrealit's not a 1:1 feature set, although bytecode has features streampack was intended to have
  63. blueyou're mixing milk and meat. port stuff over until streampack/old nevet is obsolete, then delete it
  64. dreamrealnot just obsolete, replaced, then, which is more or less what I'd intended to do
  65. blueyes
  66. blueI wouldn't invest time in merging repos, seems like a timesink to me with little gain
  67. dreamrealas usual, you're a wonderful person who requires only a moderate amount of tolerance
  68. blueI give you the raw unadulterated truth. at the mild cost of current annoyance, you avoid falling on your face later
  69. blueit's also called the min-max principle
  70. blueminimise dumbness, maximise immediate action
  71. dreamrealSure. Yet you also make sure to offer opinion, and the opinion is distracting from the truths.
  72. blueya. just remember that 99% of what humans say are opinions
  73. blue'truth' is just an SEO term we use to make our opinions sound more legitimate to ourselves
  74. bluetake it with a grain of salt
  75. blueespecially MY opinions
  76. dreamrealYet we can always write clearly such that our opinions don't get in the way if we're baseline competent. If.
  77. dreamrealFor example, I could have just decorated that last statement with "and krautrock suxxxx!"
  78. blueyes
  79. 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
  80. dreamrealOf course! The "if" at the end was a twisting of a knife to illustrate a point.
  81. 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
  82. dreamrealonly for people who fail the metric regularly.
  83. bluefair
  84. Chronosdreamreal: Oooh, tags. +100 for tags.
  85. dreamrealTag support has been in since early days, but apparently SOMEONE forgot to search for them specifically. Fixed.
  86. Chronosdreamreal: Side note: Thank you for supporting dark mode.
  87. ChronosMy eyes have always been, shall we say, imperfect. Dark mode is much easier on them.
  88. dreamrealon the sample content site?
  89. dreamrealor my website?
  90. 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.
  91. bot[jottinger/bytecode.news] New issue #66: Rename repository from bytecode.news to streampack - https://github.com/jottinger/bytecode.news/issues/66
  92. bot[jottinger/bytecode.news] New issue #65: URL summarization with blog draft creation - https://github.com/jottinger/bytecode.news/issues/65
  93. bot[jottinger/bytecode.news] New issue #64: Channel/user sentiment analysis operation - https://github.com/jottinger/bytecode.news/issues/64
  94. bot[jottinger/bytecode.news] New issue #63: Poetry generation and analysis operations (LLM chaining test) - https://github.com/jottinger/bytecode.news/issues/63
  95. Chronosdreamreal: On your website.
  96. dreamrealChronos: you have blue to thank for that, he pushed me into it
  97. 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. :)
  98. Chronosblue: Thank you!
  99. ChronosI can tolerate white, but it does hurt my eyes.
  100. dreamrealme too, I just don't design UIs at all so the L&F was very default
  101. 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.
  102. dreamrealPerl noob, eh
  103. blueyw, dreamreal
  104. bluedreamreal: I've finally found a *somewhat* acceptable way to manage separate browser profiles per web app
  105. blueso in the case of discord, I have this:
  106. blue spawn-sh "brave --app=https://discord.com/app --user-data-dir=$HOME/.config/web-apps/discord";
  107. nevetspawn-sh "brave --app=https://discord.com/app now has karma of -1.
  108. 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
  109. dreamrealheh
  110. 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
  111. blueit also makes XSS attacks moot: if you're only logged into one website per profile, there's no other profile to be hijacked
  112. bluesomething like `<a href="https://my.bank?sendto=dreamreal&amount=120" class="hidden"></a>` becomes impossible
  113. 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
  114. 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
  115. 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
  116. bluedreamreal: substack was hacked, fyi
  117. dreamrealwha? url?
  118. bluewife told me should got an email aobut a notice of a security breach, you should have got one as well
  119. blueshe got*
  120. bluethey claim emails and phone numbers were leaked. I'd consider all data leaked, tbh
  121. dreamrealhaven't gotten one yet, and substack has none of MY information on it; my id on substack is entirely obfuscated
  122. dreamrealthey don't even have my phone number or main email address
  123. bluehttps://haveibeenpwned.com/Breach/Substack
  124. nevetblue mentioned url: https://haveibeenpwned.com/Breach/Substack ("Have I Been Pwned: Substack Data Breach")
  125. bluehappened oct 2025, blew up now
  126. dreamrealwow
  127. blueit doesn't matter: I suggest you'd recycle your password for good measure anyway, if you have one
  128. dreamrealyeah
  129. bluehttps://www.csoonline.com/article/4128287/substack-data-breach-leaks-users-email-addresses-and-phone-numbers.html
  130. 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"
  131. blueWelp, the confirms the notion that you should never store passwords if you can help it
  132. bluethat*
  133. dreamrealyeah, that's an issue for this app too
  134. blueunless you're an email provider or other source of truth provider, storing passwords not very smart
  135. dreamrealyeah, I want to use oauth or something else, but that's definitely not a strength for me
  136. blueI'd even argue that storing passwords for a secondary, non-source of truth website, has zero benefits
  137. blueit doesn't increase security: people who have access to your source of truth can typically reset passwords
  138. dreamrealI don't think I'd argue against that assertion :D
  139. 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
  140. bluealso technically I'd argue that magic links offer stronger assurances on identity
  141. bluejust knowing a password is weaker than "I have access to this account's source of truth"
  142. dreamrealYeah. MY problem is that I am behind on security design for that surface
  143. bluethat WILL become an issue for you once the frontend gets more focus/attention
  144. dreamrealIt might be good to focus on it before it deploys, then
  145. dreamrealbetter to get it as right as possible before we commit to a published design
  146. 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.
  147. 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
  148. dreamrealI loved perl back in the day :(
  149. bluethe magic link table is simple, too: id: primary, code: string, created: Date
  150. Chronosblue: I agree that browsers, by default, should be completely separated contexts per domain. Although that'll never happen. :(
  151. blueyou could even use the code as primary since it needs to be unique anyway, but I'd add id for good measure
  152. 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
  153. dreamrealblue: so what would that do: "to log in, click here, then check your email"?
  154. dreamrealclick the email link, bingo-bango, you're logged in?
  155. 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
  156. dreamrealwhich one's better?
  157. blueI prefer the latter approach, it's a bit more secure since you can tie the frontend session to the sent code
  158. Chronosblue: yep. They even "gave up" on their whole "no third party cookies" things. Which seemed like the minimum they should do
  159. dreamrealHmm, I wonder how that'd be integrated into the auth system
  160. dreamrealcan you file an issue for it?
  161. bluesure
  162. dreamrealthank you
  163. 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)
  164. blueinside the <form> tag, you'd put something like the record's id, from the db
  165. blueanyway, I'll keep the details to the gh issue
  166. bluedreamreal: https://github.com/jottinger/bytecode.news/issues/67
  167. dreamrealGrazi! (and nevet will inform us of it soon enough!)
  168. bot[jottinger/bytecode.news] New issue #67: Passwordless authentication via email one-time codes - https://github.com/jottinger/bytecode.news/issues/67
  169. dreamrealand there it is! Good issue, BTW
  170. dreamrealtodah
  171. bluewelcome
  172. blueadded a small bit about expiry, which I'd forgotten
  173. blueobviously you can choose any other value than 10 minutes, some websites do 20 minutes. I think 10 minutes is good
  174. bluethe higher your desired security level, the lower the cutoff time
  175. 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
  176. bluethe check itself can occur postauth, and then you fork on login/account creation
  177. 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
  178. blueseparate*
  179. ChronosDoesn't Slack do that authen-via-email thing?
  180. bluepossibly, it's fairly common today
  181. blueslack is not an ID provider so I'd argue it fits
  182. 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...
  183. 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
  184. 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
  185. blueif you don't store passwords you eliminate an entire error category
  186. bluesimilar to payment data: that's why you don't store CC details, normally
  187. bluesome websites store like the last 4 digits for verification, but today you'd just store a token from stripe or whatever
  188. blueanything that's sensitive should be stored at its source of truth
  189. bluebanks, email providers, payment providers... those usually have dedicated security team.
  190. blueteams*
  191. Chronosblue: Don't most services store hashes instead of passwords?
  192. dreamrealthey do but that's not really sufficient
  193. ChronosAnd use some combination of user name, salt, and password to generate the hash? Making it harder to brute force the password.
  194. * Chronos isn't a security person, so only knows some high level basics.
  195. dreamrealharder != sufficient
  196. ChronosWhat would be sufficient?
  197. dreamrealfor password storage? It's a moving target, that's the whole problem
  198. dreamrealit used to be a salt+encrypt, but computational increases meant that could be broken
  199. ChronosMy assumption is there is no perfect solution, just good enough solutions.
  200. 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"
  201. 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
  202. dreamreali.e., hit the app, export the data, use the data before it expired...
  203. * Chronos is sufficiently unfamiliar with email to know how secure it is these days.
  204. dreamrealemail itself, meh, the providers are responsible for it
  205. ChronosIf I personally ran a website, I'd seriously consider washing my hands of authentication complexity, and using emails for that.
  206. ChronosMost websites have some kind of flow for resetting passwords via email anyway... so...
  207. 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
  208. dreamrealmore securer.
  209. dreamrealIt also has a lot less of a burden for ME, and I'm all for that!
  210. 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.
  211. blueit could be long enough that it's irrelevant, the systems/people are already dead, but it could also be tomorrow
  212. bot[jottinger/bytecode.news] New PR #68: Adding poetry operation and ai module - https://github.com/jottinger/bytecode.news/pull/68
  213. * nevet joined #nevet
  214. * 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
  215. dreamreala poem: roses are red/violets are blue/omg that guy reeks
  216. blueChronos: if bytecode should not ever assert ownership of identity, then it may practically not store passwords
  217. bluethose two sentences are effectively the same thing
  218. * dreamreal taps the glass
  219. dreamrealpoem sunsets with indigent cats
  220. 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.
  221. 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.
  222. 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.
  223. bluethe whole 'reset your password via email' thing is a chain of trust, anyway; passwordless logins generalise this concept
  224. bluewhilst getting rid of the footgun which is storing passwords
  225. dreamreala poem: roses are red/violets are blue/omg that guy reeks
  226. 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.
  227. * nevet joined #nevet
  228. * 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
  229. dreamrealpoem epic potato chips
  230. neveta poem: Golden discs of crispy fate,/Salt-crowned treasures on my plate./Crunching thunder, flavor bold—/Each chip worth its weight in gold.
  231. a poem: Golden discs of crispy fate,/Salt-crowned treasures on my plate./Crunching thunder, flavor bold—/Each chip worth its weight in gold.
  232. 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.
  233. dreamreala poem: I hope that Chronos/Eats his children/More rarely/Than Saturn Do./WORD.
  234. 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.
  235. bluea poem: Awoke dead. Woke dead. Oke dead. Ke dead. E dead.
  236. 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.
  237. * dreamreal giggles
  238. bluehe totally missed the social criticism...
  239. dreamrealOf course. And there are length constraints on the analysis, too. And stop gendering an LLM!
  240. blueyou fool, nevet is a male word in hebrew
  241. dreamreala poem: I hope that I/can eat my pie/While in the sky/But I'm not high
  242. 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.
  243. dreamrealthe LLM is ungendered though
  244. dreamrealanyway, the chaining works
  245. blueshrug, it's all nevet to me! if I hebrew, he'd say 'he'
  246. dreamrealwhich is the whole point
  247. bluespoke hebrew*
  248. dreamreal*nod* I get it, nevet is male, the llm is not, this is all proxied
  249. dreamrealokay, that means the AI infrastructure works AND the loopback stuff is in place
  250. blueyou know what's also proxied? CONSCIOUSNESS!
  251. dreamrealnow I get to look at the userauth stuff again :/
  252. bluehahahaha
  253. dreamrealThe summarization stuff for channels and urls is actually really important going forward, but userauth is a little more core
  254. 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
  255. dreamrealblue: so... we need to think about the auth a little more, because of REST
  256. bluedreamreal: shouldn't REST be per oauth?
  257. dreamrealI mean... the UIs would use it
  258. blueyou mean the frontends will use rest to communicate with the backend?
  259. dreamrealthey damn well should, yes
  260. dreamrealthey should have no access to the underlying system
  261. blueand in case of auth'd operations, you send the user's jwt token with the request?
  262. dreamrealYeah
  263. bluethat sounds pretty straightforward to me
  264. dreamrealI'm iterating on the issue, will have comments for the issue soon for your review
  265. dreamrealI can't adequately evaluate UI issues, IMO
  266. blueacknowledged
  267. Chronosdreamreal: Rather than "echo a signal we sent to someone we presume is you," what about emailing users a magic temporary URL?
  268. dreamrealChronos: give me a sec, writing a comment that captures my thinking
  269. 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!
  270. Chronosblue: Yep, that makes sense — I love the idea of not storing passwords at all.
  271. dreamrealMe too
  272. dreamrealblue's nowhere near as stupid as people say! ... just as annoying, though. :D
  273. bluethe annoying bit is a feature, not a bug
  274. dreamrealyeah, that's what you keep saying
  275. Chronosdreamreal: What don't you like about the magic URLs?
  276. Chronoss/magic URLS/magic _temporary_ URLs/
  277. Chronos(I'd give the user ~10 minutes to use the magic temporary URL emailed to them.)
  278. dreamrealWell, the magic url is yet another path for the UI to follow, for one thing
  279. 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
  280. dreamrealplus, the magic code path is easier to localize per UI (I am hoping the initial ui deployment has two execution paths)
  281. 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.
  282. dreamrealso I am hoping to have nextjs.bytecode.news and primate.bytecode.news on day one, with www pointing to whichever one is best
  283. dreamrealChronos: yeah, I get it
  284. dreamrealI just think it binds the url to a specific UI
  285. blueConsider this, Chronos. A magic URL is something you could by accident send someone, granting that person full access in your name
  286. blueIt's not inherently a problem, but an avoidable one
  287. ChronosAh. Hmmm. Legitimate reasons.
  288. blueThere's also the ages-old idea that GET should be idempotent. Magic URLs violate that principle. They incur a login.
  289. blue(itempotent and not stateful, that is)
  290. ChronosYou guys have definitely thought this through.
  291. dreamrealI can't say *I* have!
  292. * Chronos chuckles
  293. dreamrealI'm winging ALL of this, man
  294. dreamrealpoem flying by the seat of someone else's pants
  295. 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.
  296. 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.
  297. 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.
  298. ChronosI like that y'all are discussing this. I get *so exhausted* of all the bikeshedding in software engineering.
  299. blueMagic links are *still* better than passwords: however, I'd consider passwordless auth the gold standard.
  300. ChronosThese days, the words "best practices" make me want to break down and weep unconsolably.
  301. bluewell yeah, best practices is performative nonsense
  302. 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!
  303. ChronosI think I misused the word bikeshedding above.
  304. 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
  305. ChronosI think I should have said... something about being a lemming...
  306. dreamrealyakshaving?
  307. dreamrealspherical cow-moulding?
  308. ChronosOne thing I *don't* like about magic links is now you have *two* browser windows.
  309. dreamrealI think I could have this auth code stuff written for the back end by tomorrow
  310. Chronosdreamreal: Regarding getting it right: dreamreal+=1
  311. Chronos^^^ Bug. Karma module should pick that up.
  312. Chronos(Just kidding)
  313. blue"The 202 response is returned whether or not the email exists in the system (prevents account enumeration)" < this is good
  314. dreamrealbut I want to make sure we're doing it right
  315. dreamrealChronos: heh
  316. Chronosdreamreal: How are you handling the sending of emails? Using a third party service?
  317. dreamreal+1 and -1 was thought about - as was the "^^" signal indicating agreement
  318. dreamrealChronos: MTA locally
  319. blue"This means fishing with a fake email is harmless: the OTC record expires in 5 minutes and nothing persists." agreed
  320. dreamrealyou configure which MTA you want to use and it gets used :D
  321. 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
  322. blue"Issuing a new code invalidates all previous codes for the same email
  323. blue"
  324. bluethat is stronger than the guarantees I offered, but why not
  325. 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"?
  326. ChronosThose first two and last two emails are identical.
  327. dreamrealChronos: well... okay, so the way nevet handles users, the email is actually irrelevant
  328. blueChronos: read dreamreal's write-up, I believe it handles that
  329. dreamrealthere's a principal and the principal has related identities
  330. dreamrealon IRC, it uses SASL to validate, and an admin HAS to set that up
  331. 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
  332. blueScheduled cleanup purges expired records
  333. bluebit conflicted about this
  334. bluetechnically, it's ok... why not reuse codes, in theory
  335. 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
  336. blueI guess I'm overthinking this, I don't really care in a 16.7M space
  337. dreamrealhttp authentication is the SAME AS IRC in structure: it's an identity that resolves to a given user principal
  338. blueit does adhere to the idea that the code is time-bound, anyway, so all good
  339. 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
  340. 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)
  341. blueChronos: https://github.com/jottinger/bytecode.news/issues/67#issuecomment-3929533643
  342. ChronosThank you good sir.
  343. blueyw
  344. ChronosMy vision issues are hella annoying.
  345. ChronosIt's really hard for me to spot "stuff" in a sea of text.
  346. dreamrealhttps://github.com/jottinger/bytecode.news/tree/main/lib-core/src/main/kotlin/com/enigmastation/streampack/core/entity <-- see User and ServiceBinding
  347. ChronosLike, extra double deluxe family size hard.
  348. dreamrealI get it :(
  349. dreamrealso the token stuff we're talking about is for a *specific* service binding, over HTTP
  350. ChronosMy IRC client does a good job helping to distinguish some key things though.
  351. dreamrealIRC, DISCORD, SLACK are all different services and have different binding mechanisms, so this is scoped almost exclusively to HTTP
  352. ChronosOff to eyeball those pages :)
  353. 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.)
  354. 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.
  355. bluedreamreal: ack'd
  356. bluethe addition of the email to the table for rate-limiting is good
  357. dreamrealblue: so the next question for YOU is: how difficult would it be to leverage that mechanism from a UI?
  358. dreamrealI mean, you're one of the people who'd have to use this
  359. dreamrealif the answer is "AGH I'd rather bite off my own neck" then there's a problem
  360. bluehm
  361. bluewell, I'm wondering where is the association in POST /auth/login
  362. blueboth email and code are known
  363. blueshouldn't it rather be id and code?
  364. dreamrealWhich id would that be, though?
  365. dreamrealthe internal userprincipal id?
  366. bluethe uuid (v7) column
  367. 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.
  368. dreamrealChronos: arabic! You're talking to two Jews here!
  369. bluelol
  370. Chronoshahahaha :)
  371. * dreamreal scoffs. Arabic numerals. Pfft. We'd be better off using 0-9.
  372. blueI don't disagree with Chronos. you chose a very low cutoff time, 5 minutes. can go with 0-9, too
  373. * dreamreal points to the "comment" button
  374. blue0-9 space would be indeed easier to memorise, in case you're not a copy-paster
  375. ChronosComment incoming!
  376. dreamrealand JUST IN CASE: yes, I know
  377. dreamrealmuch appreciated
  378. dreamrealChronos: ++
  379. nevetChronos now has karma of 2.
  380. dreamrealblue: ++
  381. nevetblue has neutral karma.
  382. dreamrealblue: ++
  383. nevetblue now has karma of 1.
  384. bluethat is stronger than the guarantees I offered, but not continuity
  385. blueugh, wrong message
  386. bluedreamreal: sending the email and code in the 2nd step proves account ownership, but not
  387. bluecontinuity
  388. dreamrealwhat do you mean when you say continuity?
  389. ChronosComment added!
  390. blueonly the user who initiated the process can finalise it, in the same browser tab
  391. bluethat only works if the frontend knows the id
  392. ChronosOK, back to reading the rest...
  393. dreamrealWell... so the *last design* (from my comment) doesn't create an id until an actual token is matched
  394. blueso after step one, you can an entry in the new table, right?
  395. dreamrealI guess we could aggressively create ids, then require the id, an email, AND the token to complete it
  396. blueyou create*
  397. Chronos5 minutes can be a little tight when my Internet or email are slow. 10 minutes suggested.
  398. dreamrealChronos: get good internet, loser!
  399. ChronosWell, happily, mine is crazy good, these days! Fiber ftw!
  400. dreamrealblue: in the design I was thinking, the id is not created until after step 2
  401. blueso let me rephrase this. after step 1, you create an entry in the new table, containing the code, right?
  402. blueid/email/code/create_at <- that row gets created after step 1
  403. dreamrealI guess we could do it earlier but that implies a cleanup of stale accounts (from a "have they ever logged in?" perspective)
  404. bluecreated_id*
  405. blueI'm talking about the new table, not about user accounts
  406. bluethe one_time_code table
  407. dreamrealAh, right, okay, so you're talking abotu an EPHEMERAL id, not one associated with the account itself
  408. dreamreal"this is the id of the login token"
  409. blueyes. I'm talking about the id of the record of the new table (under Database changes, New table:)
  410. blueI'd expect *this* to be returned after step 1, and be reused in step 2
  411. bluealongside the code
  412. 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"
  413. dreamrealam I understanding this correctly?
  414. blueyes
  415. bluethe way it's phrased now, it'd be pretty easy to completely automate account creation
  416. bluethis is not necessarily something you want
  417. ChronosLove the passwordless authentication docs.
  418. 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
  419. blueit's then mirrored back in step 2, alongside with the code that the user provided
  420. bluethe id says: I used the browser tab that initiated everything, the code says: I am the owner of the email
  421. dreamrealYeah. I like this idea.
  422. 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
  423. blues/in your code/in your case/
  424. dreamrealYeah, the email isn't important internally anyway.
  425. bluewell I suppose it's not entirely irrelevant: it can be used to match the account / prefill the account creation form
  426. dreamrealYeah, but it's just paperwork at that point
  427. blueyep
  428. 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"
  429. blueyes. the nonce is the "I am here physically", the code is "I know something"
  430. ChronosIt would be nice to be able to change email addresses
  431. dreamrealwell, we will have profile updates, that's captured as PUT /auth/profile
  432. ChronosOh, ok, sounds good
  433. dreamrealchanging email address is probably a downstream concern, actually... or even a "hey, email an admin for this" concern
  434. 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"
  435. bluedreamreal: since you're storing the email in the table... you don't have to send it in step 2
  436. dreamrealyeah, I know, it's just extra, and you know how much I like being extra
  437. blueyou're already enforcing one code per email, anyway. code uniquely points at email
  438. bluealrighty
  439. 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.
  440. dreamrealChronos: it causes me great pain, personally, too, because that HAPPENED to me
  441. Chronosdreamreal: How?!
  442. dreamrealnamecheap let a domain expire with a warning that I missed
  443. Chronosoh crap
  444. 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"
  445. ChronosI've gotten to the point in my life where I'd prefer to pay for the next 30 years up front.
  446. dreamrealexcept the all caps was in bright flashing neon
  447. dreamrealThe new squatter offered to sell me my domain back for $25k :D
  448. dreamreali was like "WOW enjoy it mate"
  449. Chronosdreamreal: Jesus. What was the domain? If you don't mind sharing.
  450. dreamrealautumncode.com
  451. bluedreamreal: thinking about this in terms of flexibility: how about returning a JWT in step that has a CREATE_ACCOUNT_ONCE privilege?
  452. dreamrealI'm sure you've heard of it quite a lot. It had one page on it, a landing page.
  453. ChronosIt's still for sale :)
  454. dreamrealChronos: yeah, no-one is going to buy it. Ever.
  455. 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.
  456. Chronos"Get a price in less than 24 hours" — Yeah, no. If you can't tell me the price up front, go fuck yourself.
  457. Chronos(Talking to GoDaddy, heh)
  458. dreamrealblue: Would we NEED that? I mean, wouldn't that come out of the flow anyway?
  459. dreamrealChronos: Well, I *did* get a price out of them, but it definitely made me laugh
  460. dreamrealbut replacing my email address on services has been a drag
  461. 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
  462. 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...
  463. 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.
  464. dreamrealblue: diagram it out! I mean, if there's a good way to go here, I'm for it!
  465. dreamrealChronos: it wasn't my primary, thank God - that's actually on a different service altogether - but yeah
  466. dreamrealblue: remember, on the HTTP auth side *I consider myself a newbie and ignorant*
  467. dreamrealif there's expertise I am *all for* leveraging it
  468. 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
  469. bluehm, maybe it's too complex and account creation needs to be automated
  470. bluelol, andrew just pooped all over the issue
  471. dreamrealnah, it's fine, we don't shut down conversation about it
  472. dreamrealI mean, he's not wrong, it's just that *I* don't know how to externalize all auth
  473. dreamrealhe may
  474. 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.
  475. 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
  476. blueI don't know what he's gonna suggest, but you need ACLs *anyway*. even if you just do auth by google
  477. blueyou're STILL gonna save dreamreal@gmail.com SOMEWHERE
  478. dreamrealThe ACL is already there
  479. bluehe's being ridiculous
  480. dreamrealI dunno about that
  481. dreamrealI'm not sure I know what he's suggesting
  482. blueneither do I
  483. dreamrealso let's do the smart thing and find out!
  484. dreamrealpoem messing around and finding out
  485. 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.
  486. 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.
  487. 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.
  488. 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.
  489. ChronosI don't mind giving some websites my email address, but I don't want my accounts magically automagically linked to my Google Account.
  490. blueChronos: ya, as noted about, it's also completely broken. auth-by-email is a simple, secure replacement
  491. dreamreala poem: andrew is a fartknuckle/his hair as white as lard/and every time he speaks his mind/I think 'what a canard.'
  492. 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.
  493. bluemy point is that dreamwould would need to build some kind of auth flow ANYWAY, even if he just ends up using google oauth
  494. bluethere's no kind of work being 'saved' by andrew's suggestion here, as far as I can tell
  495. dreamrealWell, I have a feeling the gesture is "use oauth" as opposed to "use google oauth" but yeah
  496. dreamrealwell, let's see what he says
  497. bluehe might have misunderstood: passwordless email auth is conceptually the same thing as delegated oauth
  498. blue"why build this at all" is moot. this is the minimum you need to build, anyway (perhaps bar the table)
  499. dreamrealsure. But let's HAVE THE CONVERSATION. Architecture by fiat is doable, but if we can build consensus it's better.
  500. blueright
  501. ChronosPassword-Less Email Authentication (PLEA)
  502. blueya
  503. Chronos(I thought I was being inventive and clever there)
  504. dreamrealworking on infrastructure for sentiment analysis now
  505. blueya I noticed
  506. dreamrealChronos: did you catch my message about the url summary stuff?
  507. blue~sentiment
  508. bluehm, broken
  509. dreamrealnot implemnted yet, I'm coding it NOW
  510. * blue does snail-imitating noises
  511. dreamrealgolly
  512. 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
  513. Chronosdreamreal: No, I missed it
  514. ChronosLooking now
  515. dreamrealsee 14:28
  516. dreamrealassuming EDT, whch is the only REAL timezone that matters, of course
  517. bot[jottinger/bytecode.news] New issue #70: Migrate service-rss to use lib-polling - https://github.com/jottinger/bytecode.news/issues/70
  518. bot[jottinger/bytecode.news] New issue #69: Migrate tell operation to use provenance override on OperationResult.Success - https://github.com/jottinger/bytecode.news/issues/69
  519. bot[jottinger/bytecode.news] New PR #71: Adding sentiment operation - https://github.com/jottinger/bytecode.news/pull/71
  520. * nevet joined #nevet
  521. * 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
  522. dreamrealsentiment #nevet
  523. nevetError: Sentiment analysis requires ADMIN role
  524. dreamrealgrrr, I AM an admin!
  525. 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
  526. Chronosdreamreal: "url summary via LLM" = LLM coming up with those-urls-with-links-like-this?
  527. * NeXeN joined #nevet