* 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
* 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
* NeXeN joined #nevet
* 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
dreamrealgithub subscriptions
nevetNo active subscriptions for this channel
dreamrealgithub subscribe jottinger/bytecode.news
dreamrealgithub subscriptions
nevetNo active subscriptions for this channel
dreamrealhmm, okay
dreamrealgithub list
nevetjottinger/bytecode.news
dreamrealokay, so that works
dreamrealgithub subscriptions
nevetNo active subscriptions for this channel
dreamrealgithub subscribe jottinger/bytecode.news
dreamrealhrmm, the worst part is that I get no errors from that command. Working on it.
* 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
dreamrealgithub subscribe jottinger/bytecode.news
dreamrealOH
* 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
dreamrealgithub subscriptions
nevetjottinger/bytecode.news
dreamrealbeauty.
dreamrealokay.
dreamrealI forgot that I'd hardened the user associations :D
blueyou certainly did
bluetell me when it's done. I need it for my stuff (irc/discord)
dreamrealDiscord user association is unworkable, discord doesn't auth well enough
dreamrealbut I'm waiting to see if the polling works for github
blueI don't get it. you neither need a user association nor polling. the interested repo user configures a webhook and you listen at the path, ez bananas
dreamreal... webhook
blueyes, webhook
dreamrealthat's a push mechanism
blueyou know, that thing that's not a dumb polling
dreamrealI'm trying to avoid push mechanisms
bluethat's dumb
* dreamreal eyes the fediverse
blueit's a simple POST event
blueand you can signature verify it
dreamrealI mean, not really, because the bot right now has *no* exposure and no requirement for it: it gets the information it needs, polling is rare just because I usually don't CARE to find out the second something happens
dreamrealand there's NOTHING in the system that prevents an interested party from making a webhook for it
bluewebhooks are the lazily "come to me when you're done approach". polling doesn't scale once you have many configureds. you might even get blacklisted by gh
blueyou're barking up the wrong alley
bluechange course
dreamrealAfter all, the factoid service publishes endpoints, too, and in the same manner: they'd just say "here's the endpoint for this" and someone would configure an endpoint
dreamrealand no, *nevet* is controlled by me, I'm not going to be adding so many repos that it violates GH's terms of service
blueif you ever sold it as a service, it would need to scale
dreamrealif YOU want to run the bot, you're welcome to do so: for YOUR purposes, you might want to disable the github polling service (or just don't add any endpoints) and provide the webhook
dreamrealI'm building a system, not a service
bluethat's semantics!
bluewebhooks are clearly the superior solution here, we did polling like 20 years ago
blueit's also the official path that gh recommends for repo updates
blueplus, you get nice comfy JSON!
blueI don't even *know* what you're polling against now
dreamrealI already get nice comfy JSON. And like I said, feel free to write it; the system's right there.
bluebut github can end up captching you and you'd end up with the xcancel issue
blueyeah uh, I'm gonna leave kotlin for another, preferably rainy day :P
dreamrealI'm using their access points via a library. I mean, a webhook is not conceptually difficult to DO - but deploying a webhook for functionality RIGHT NOW means spinning up endpoints I don't want to spin up yet.
bluewhat's the cost to spinning up endpoints
dreamrealdeployment, exposure of the rest of the API before it's tested, potential multiport access, etc
dreamrealActually, the way I'd LIKE to do the webhooks is via a proxy: set up a different service altogether that has connectivity to nevet directly (AMQP/HTTP/MQ?) and events get into the system like that
dreamrealThere are going to have to be public endpoints with visibility for the content system, factoids, etc, etc., so it'd be conceptually FINE to set up a direct webhook interface... but nevet's still got the shiny wrapper on it in a lot of places and I'm not ready to solidify the endpoints. So that gets to wait.
dreamrealIf that's enough of a burr, well, that's fine! nevet's open source! Fix it! Harden it! Help me get the UI nailed down, even if you're not writing the UI! This is a system in active development and stable APIs aren't.
dreamrealfor that matter, part of what drove the github mechanism was that I wanted a generalization for polling - RSS uses it, and I was thinking there's a model here, as opposed to re-writing RSS "for github." RSS doesn't use the polling system github does here, because I wanted it to work before porting it over.
dreamrealI don't want to support fediverse enablement, but that would *require* webhooks; it's not a foreign concept, it's just a waterfall I'm not quite ready to jump over yet when I don't see the need. (github's TOS, btw, are REALLY generous for polling access - like, you'd have to go NUTS to subscribe enough to make polling a problem.)
dreamrealand since nevet has one and only one admin..
dreamrealmaybe not as nicely as you'd like, it's definitely a poll and not a webhook, but it's functional.
bluethis is where I think stuff gets too verbose. better to create a short url bytenews/gh/1234
dreamrealNothing prevents that kind of mechanism in the system
blueowning the urls also means you could add tracking -- if you're into that, anyway
nevetowning the urls also means you could add tracking now has karma of -1.
dreamrealit just presumes services that may not be present.
dreamrealhaha
dreamrealemdash for the win :D
blueyou really gotta make him less dumb :P
dreamrealanyway, the whole thing is built on a message chaining system: getting a url that has an internal source could indeed get a shortcode. It's just not important TO ME so I haven't written it.
dreamrealAnd that's not "less dumb," that's a length filter on the subject of a karma operation that didn't get tripped.
bluein other words, dumb
dreamrealNot really: it's working as intended. "so-and-so doing the stupid thing despite every warning that it's stupid--" is a legit karma operation.
nevetNot really: it's working as intended. "so-and-so doing the stupid thing despite every warning that it's stupid now has karma of -1.
* dreamreal grins
dreamrealWe're not trying to build semantic reasoning into a KARMA operation. If that's desired and you have the CPU and the models for it, well, cool: nothing precludes yeeting the detection and hooking an LLM or an NER into it. But that's not the way IRC karma normally works because that's expensive and ridiculous.
dreamrealmost of the bot's operations are proofs of concept in any event: they're designed to be functional and useful, eventually, but they're very much "hey, what about this use case, does this make sense?" The 21 matches thing is a good example of that: as a game, hah, it's pointless; the bot always goes second, it always wins. But as a proof of concept, it demonstrates functionality.
dreamrealGithub is the same thing: RSS and the github integration functionally work VERY similarly, but github integration uses a common model that RSS implied; eventually I'll move RSS over to it because it reduces maintenace burdens. Factoids, dictionary... heck, the dictionary thing came straight out of the JSR/JCP/RFC functionality, and so did PEP: "What does it take to expand this?"
blueyou don't need to build semantic reasoning to detect a " -- " and exclude it
nevetyou don't need to build semantic reasoning to detect a " now has karma of -1.
bluejesus
dreamrealOkay, so let's play a game: what rules would YOU use to exclude em-dashes?
blueSPACES AROUND
blueas I just demonstrated
dreamrealBut spaces are legitimate
dreamrealblue: --
nevetblue now has karma of -1.
bluethey shouldn't be: and you're trimming anyway
dreamrealblue:++
nevetblue has neutral karma.
dreamrealSo if I'm TRIMMING how would I detect them?
bluedetect SPACEDASHDASHSPACE and exclude. this isn't hard
bluethat's the in-sentence use of them, rather than a decrement operator
dreamrealIt's also semantically incorrect, and relies STILL on human engineering. It fits YOUR pattern.
blueno, it fits the EXPECTED pattern. the karma operation should not MISDETECT normal conversational patterns
blueask anyone, he'd tell you it's dumb
dreamrealbecause I use completion as well: if you use "name em-dash foo" that's an IRC completion for the name, the em-dash for the op, and foo for the comment
dreamrealOh, I still disagree: karma on irc is usually incredibly dumb, way dumber than I've made nevet, honestly
dreamrealyou're looking at progress and going "OMG it's not enough" :D
blueas soon as a playful operation disrupts a normal conversation, it's a negative sum thing
dreamrealI built nevet's karma evaluation based on how I've actually seen it used and how I've seen it WANTING to be used over decades of infobot execution. Yes, there are false positives. They're endurable, mostly because they're going to generally be VERY unique: nobody's likely to query karma for a long text prefix by accident.
blueyou could literally fix this error by checking for the exact pattern I laid out above
bluethis is a no brainer
dreamrealI hear you, but IRC conversations are async and are ultimately trivially interrupted and disrupted in any event. No, you can't, because that actually KILLS a lot of legit decs
bluethis is NO legitimate use case for karma using SPACEDASHDASHSPACE
blues/this/there/
dreamrealblue ++ you're right
nevetblue now has karma of 1.
dreamrealblue -- you're wrong
nevetblue has neutral karma.
dreamrealblue -- wait which is it
nevetblue now has karma of -1.
blueI don't even know that what means tbh. you write something DASHDASH COMMENT?
dreamrealI just did...
bluethen drop the comment, OR force people to write SOMETHINGDASHASH with no space, by excluding the pattern above
dreamrealno, because that implies arbitrary rules that are SURPRISING. The rules right now aren't surprising. They're vaguely annoying to you, but they're consistent.
bluethe rules are now are TOTALLY surprising. you write a NORMAL CONVERSATIONAL sentence, and the dumb bot repeats it and creates a garbage entry in your db, to boot
bluewith garbage I mean: it will NEVER be updated
blueit will also never be queried
dreamrealOh no, those records are so expensive, oh no. But it's still not surprising, because users learn that the operations are consistent. There's not a difference when an em-dash occurs in this subject vs THAT subject: "why didn't it work?" "Did you use spaces?" The places where it gets rough are when you have legit emdashes in names
dreamrealc--++
nevetc-- now has karma of 1.
dreamrealAnd you're wrong_ teh system actually purges old data.
blueoh man, this is the wrong hill to die on. it's the reason I ended up kicking nevet from the discord server the last time. becuase I wasn't able anyone to use double dash in my sentences without him disrupting the flow. you're hung up a perfect idea of a theory that is nonsense in practice
dreamrealKarma erodes; after about 350 days or so it approaches asymptotic 0.
blues/anyone/anymore/
* dreamreal shrugs. You can ALWAYS run nevet yourself and mutate the operations as you like.
dreamrealC++--
nevetC++ now has karma of -1.
blueyes, no space there
blueI *could*, but this is actually a GOOD suggestion. ask anyone. I doubt you'd find one person in agreement with you on this
blueand the annoying part is that I could massively benefit from nevet, but this is a deal breaker if you want to be able to use em dash in your sentences
* dreamreal sighs. I guess the whole "I designed the function after watching how people use karma on IRC for decades" slipped right under your radar.
dreamrealIf it's that big a deal, TURN OFF KARMA.
blueso I have two choices, *if* I want to keep use it: remember NOT to use em dashes in my sentences, or tolerate the pesky bot interjecting every time I do
dreamrealAlmost everything nevet does is optional.
blueyou can turn off karma per discord server / irc channel?
dreamrealNo. You can turn off karma. You don't need it. It's always been a toy.
bluebut then I need to run the bot myself
dreamrealAnd...
dreamrealI mean, you want YOUR configuration. Why wouldn't you run it yourself?
bluebecause the threshold for a bespoke configuration isn't met. I'd need to run the entire bot myself just to turn off an entire feature because you refuse to create a super meaningful exception
dreamrealthe bytecode.news thing is a... wait for it! It's an option! You don't have to run the content system AT ALL. No front end, none of it.
dreamrealIt's an exception that runs counter to what the author for the plugin wants. And it's not a terrible idea to have karma on or off by channel, actually.
bluewell in the case of discord it'd be the entire server
dreamrealAnd I refuse to create an exception for an operator that runs counter to how the operation was designed yes. "A car with round wheels but with wheels that are square, please" - no.
* dreamreal shrugs. I mean, turning off a feature by provenance wouldn't be a terrible idea, it's just something I'd have to figure out how to map. karma operation syntax is really simple right now and should remain so.
dreamrealIt's a LITTLE complicated because we're programmers and languages like c + + exist.
dreamrealBut the mode is simple: subject, operation, comment. Comment is discarded. operation is the LAST VALID token, so subject is "greedy." Subject is length-constrained: there IS a feasible, rational limit to the length a valid subject can be, but it's generous by design.
dreamrealC+++++++
nevetC+++++ now has karma of 1.
bluethe comparison doesn't hold. this is more like, a car having a mechanism not to run stuff over, can have exceptions for a few things
dreamrealC++++--
nevetC++++ now has karma of -1.
dreamrealC+++++--
nevetC+++++ has neutral karma.
blueand your examples dn't use spaces
bluedon't*
dreamrealRight, and? The completion thing means spaces *are not relevant*
dreamrealWe don't have a completion for language names, but that's not a salient point.
blueso you just exclude spacedashdashspace, this is super easy
dreamrealIt IS super-easy. And wrong. It's a special case that is not obvious to users; there are other exceptions that are not obvious - the 150-char limit on subject, for example - but they're likely to be quite rare, whereas this one is MUCH LESS LIKELY to be rare. And expressing it is nontrivial. Besides, the emdash in conversation blows.
blueyou're LITERALLY avoid using em dash right now to not trigger your bot
blueyou're proving my point for me
dreamrealI LITERALLY rarely use emdashes in regular conversation. :D
bluebut that's the correct way to write. if you use dots at the end of your sentences or capitalise your sentences, then you should use emdashes!