Chat Logs

  1. blueinstead he wants to make it configurable... which uh.. is ok, doesn't make the default behaviour any less quirky
  2. blueso basically no human is gonna parse A DASHDASH B as A is the karma'd object, and B is the comment, if A and/or B are anything resembling a sentence
  3. bluehaving a karma feature is a nice-to-have. having a flowing conversation the bot doesn't lose its mind in the middle and spews nonsense is *basics*
  4. bluewhere the bot*
  5. bluethis also leads to some really weird situations (the following is a test)
  6. bluejosh -- did you read my pm?
  7. nevetjosh now has karma of -1.
  8. blue^ dumb
  9. * Chronos doesn't have a strong opinion on it one way or another
  10. ChronosBut I feel compelled to clean up the mess I made, so please disregard the following two messages
  11. Chronosblue: I'd probably use emdashes if I knew how to type them. I used to use ++
  12. nevetblue: I'd probably use emdashes if I knew how to type them. I used to use has neutral karma.
  13. bluelol
  14. bluere strong opinion: as you should. dreamreal and I are going to butt head on this until the messiah arrives, and it's good that way
  15. ChronosAt a guess, ignore the line if it has text that follows the ++ or -- characters.
  16. nevetAt a guess, ignore the line if it has text that follows the ++ or now has karma of -1.
  17. blueheads*
  18. ChronosWhoops, what did I do wrong there...
  19. Chronost a guess, ignore the line if it has text that follows the ++
  20. nevett a guess, ignore the line if it has text that follows the now has karma of 1.
  21. ChronosUGH.
  22. ChronosAt a guess, ignore the line if it has text that follows the ++
  23. nevetAt a guess, ignore the line if it has text that follows the now has karma of 1.
  24. Chronost a guess, ignore the line if it has text that follows the --
  25. nevett a guess, ignore the line if it has text that follows the has neutral karma.
  26. blueoh man, you just keeping polluting the db even more, LOL
  27. ChronosOh no, I was hoping neutral karma would clean up the DB :)
  28. blueanyway, dreamreal indicated karma is selfhealing
  29. blueor well, 'fades away' or whatever
  30. Chronosdreamreal: Sorry! I'm unintentionally causing chaos! :(
  31. blue--
  32. blue---
  33. nevet- now has karma of -1.
  34. blue----
  35. nevet-- now has karma of -1.
  36. bluewelp
  37. blueI prefer explicit karma, anyway. like +1 or -1. but I guess that could have other caveats
  38. dreamrealChronos: the format is subject operation comment
  39. dreamrealoperations are the inc or dec operators, and consumption for subject is greedy
  40. dreamrealSo you can do:
  41. dreamrealC++-- this language sucks!
  42. nevetC++ now has karma of -2.
  43. dreamrealOr:
  44. dreamrealC++++ this language rocks!
  45. nevetC++ now has karma of -1.
  46. dreamrealand blue likes using the emdash as a formal writing conceit, so he's like "hey I use the emdsh and it turns into a karma operation waaaaaaaah"
  47. dreamrealand he's wrong
  48. dreamreal(BTW, #java's karma works ALMOST like this, without the greedy subject bits because javabot is older code and I don't like it and I'm not going to fix it)
  49. dreamrealin practice, it's a pretty mild human interface thing: it's a little noisy when it's unintentionally fired, it's REALLY noisy when you're chatting about it
  50. dreamrealand it's possibly really noisy if you write like an AI and use emdashes all over the place
  51. dreamrealSo... I might add an option to provide a stupid special exception for squeaky whiners^W^Wspecial morons^Wcases like blue's, where some channels don't apply the emdash if it's surrounded by spaces, which is going to have problems of its own
  52. jreicherWait—I'm confused—there's a problem with emdashes?
  53. dreamrealI fully expect a flurry of bug reports about how it's not applied when OBVIOUSLY he meant to apply it, all because the parsing works on tokens and not the things he expects it to work with, and he just never realizes that I actually know how my own damn code works
  54. dreamrealjreicher: no
  55. dreamrealbut if you embed emdashes in words as part of natural grammar -- like this -- they turn into karma operations
  56. nevetbut if you embed emdashes in words as part of natural grammar -- like this now has karma of -1.
  57. jreicherThat was a joke. :) A really nerdy typographical one.
  58. dreamrealyou're a nerd
  59. dreamrealthere IS an upper bound for karma subjects, but it's intentionally pretty gracious
  60. jreicherI actually don't know how common UTF8 is in IRC clients.
  61. jreicherOr unicode? Not sure what comes down the wire...
  62. dreamreal(Sorry, nevet` was running to test the UI, and I need to get a configuration that's more specific for local execution - it needs an MTA!)
  63. dreamrealemdash in uft-8 is just two dashes - an ACTUAL emdash isn't a trigger
  64. jreicherI know. :)
  65. dreamrealso the problem is people FAKING the emdash
  66. dreamreallike fakers who want the emdash without actually using it
  67. dreamrealdamn troublemakers
  68. dreamrealI'm bitching about it because it really is annoying
  69. dreamrealbut it's late and sunday evening and I have other fish to fry, naming getting the UI working
  70. jreicherTotally get it, and the annoyance too.
  71. dreamrealLots of really good fixes today, though: and github! That's another thing he's bitched about, but he's RIGHT There
  72. dreamrealI set it up to poll, for valid reasons, but supporting push would be a huge win
  73. dreamrealit's just not super-important for ME, so it's a lower priority, and getting the UI online is the key to getting bytecode.news online for real
  74. dreamreal(nevet = bytecode.news, the content module is designed for that, and it's all just different views of a single dataset)
  75. dreamreal'night!
  76. jreichero/
  77. bluedreamreal: "writing like an AI" is actually CORRECT. most people are dumb and get it wrong!
  78. bluewhy am I even telling you that. I'm not the Chicago manual of style
  79. bluethe really stupid thing is en dash being a disparate character to the hyphen
  80. bluethe reason I use double hyphens and not em dashes isn't unicode, but rather the fact I'd need to configure my keyboard to produce it, and I'd like to stick to the base ascii set with my keyboard
  81. jreicherblue: I was taught that endash has a distinct use that sets it apart from hyphen. Not your understanding? (I'm just curious.)
  82. bluejreicher: this might be the case, but it's a distinction without a merit imho. unlike em dash, they're not visually different enough, and also people commonly use hyphen in exactly those cases you're 'supposed' to use an en dash, like Einstein-Rosen bridge
  83. bluesimplicity is king, there is no justified use for a character that looks markedly the same to another, and also isn't typable in ascii
  84. bluein most cases and many fonts, – and - look very similar or nearly identical
  85. blueyet, having a distinct character like that breaks stuff like search, where you might think they're hyphens, but you won't find them
  86. bluealtogether, an awfully dumb idea to encode endashes separately to hyphens
  87. bluewithout merit*
  88. jreicherI didn't realise endashes could/should be used in that situation. I only learned of their use for number ranges.
  89. dreamrealNot only are you not the manual of style, you're not S&W either, and I'm a professional writer, I know this stuff better than you think
  90. dreamrealen- vs em-dash is a *typesetting* thing
  91. dreamrealfor typesetting kerning, it makes sense. But we're doing DOING typesetting - we're TYPING. You don't manually align or justify your stuff on IRC; why would you? The em-dash is a similar, although more meaningful, affectation.
  92. dreamrealen- vs em- is *typesetting* and *kerning*. It's right there in the name. The difference is in width; one is the width of an n, the other the width of an m. In monospace they're the same.
  93. dreamrealit's prevalent in human writing because we learn to write by learning to READ, and much print in human history was typeset - and did I mention that em- vs. en- was a typesetting artifact? I'm pretty sure I did. And lo, we learn to write by following those who used em- vs en- in specific circumstances because of typesetting and we inherited rules that don't actually matter.
  94. dreamrealIt's like "why do we cut off the ends of pot roasts, mother?" as the old joke goes
  95. dreamrealmother goes "I don't know, my mother did it" so the girl asks grandmother, who shrugs and says "*I* cut off the ends of pot roasts because my pan was small and they wouldn't fit, I don't know whyyour mother does it, her pan's bigger than mine was"
  96. dreamrealall of this to say: I don't really care if HUMANS use em- or en-dashes, or when, or if they're consistent about it or not - humans do learn to write by learning to read, and intent is more important than presentation. Thus we don't go about saying "you used two spaces when one is correct" all the time, or viciously corecting spelling when we can. It only shows up HERE because of karma, which creates
  97. dreamrealan artificial clash when you use the affectation.
  98. bluedreamreal: the point holds, and has been pointed out by others here. Your bot breaks expectation: having a flowing conversation is WAY more important than a karma feature, which is an addon. this unexpected behaviour makes the software dumb. software should have undumb defaults
  99. blueno amount of configuration shenanigans is gonna change the point
  100. dreamrealI agree, but we disagree that the default is dumb, here, because IRC is *not* a typical human conversation. if it were spoken, IRC would be utter madness, because conversational threads are not maintained; this is an artificial albeit understandable desire on YOUR part.
  101. blueit's only artificial if you live in an ivory tower
  102. dreamrealI get it: the emdash separation feature is actually an acceptance criterion for #41. Your point is being addressed, even though I find it overly restrictive.
  103. dreamrealBut I'm not going to pretend it's anything but an affectation on your part.
  104. blueit's not an affection at all. I've been using double dashes in IRC, and generally online, for just about forever. YOU are telling me to change how I write to not trigger your dumb bot
  105. bluean affectation it would be, were I to use this style EXTRA to annoy you
  106. bluein fact I've already consciously avoided using them in this conversation, and this annoys me to no end
  107. bluedouble dashes are a pretty common replacement/representation of emdash online (in mailing lists, too), and pretending this is someone else's problem isn't a good answer
  108. dreamrealmein Gott
  109. bluedo better!
  110. dreamrealYou're like a dog with a bone on this. With all due respect: shut up. I've already filed an issue on it. You'll be able to change the behavior as you wish. You're literally straining at a gnat, all because you've cargo-culted a writing affectation.
  111. blueit's not an affectation! I disagree with the premise
  112. dreamrealAnd you can use them; this is IRC. It's pretty normal for conversations to be trivially interrupted.
  113. dreamrealYou disagree with... how em-dashes CAME TO BE and WHY? With all due respect, that IS stupid.
  114. dreamrealThey are TYPESETTING. It is IN THE NAME.
  115. bluewait what
  116. bluethe point above was about en-dashes, not em-dashes
  117. blueare you even reading
  118. dreamreal"double dashes" are an attempt to use em-dashes in forums in which they do not exist.
  119. blueit's not an attempt. it's a representation since keyboards typically don't have them
  120. dreamrealit's a freaking hyphen. A short horizontal line. That's what it is. If you were writing with pen, you'd make the line and move on.
  121. dreamrealOf course they don't, because they are TYPESETTING.
  122. blueyes but I'm not writing with a pen
  123. dreamrealYou're not setting type either!
  124. blueI'm writing online, and your bot shouldn't interfere with dumb garbage entries
  125. bluethat's like the first rule of bots, don't be annoying
  126. dreamrealSo, uh, I have a question
  127. dreamrealif you're looking at a traffic stop, going "you know, that needs a light" and the local government goes "yes, that needs a light" and puts one in, do you still complain about the light being needed after it's been acknowledged, maybe even installed?
  128. bluethis is NOT A GOOD COMPARISON, traffic lights are basics, the bot's karma feature isn't
  129. blueit's a playful stupidity, and as soon as it starts to be annoying, it's not playful and just a stupidity
  130. dreamrealThe analogy holds: #41 exists, your feature is an acceptance criteria, and you won't shut up about it
  131. blueno, the analogy is garbage
  132. blue#41 doesn't solve it
  133. bluethe defaults are still dumb
  134. dreamrealYou know, I'm removing the feature as acceptance criteria now
  135. dreamrealjust to annoy you
  136. bluethat's fair, it's your software
  137. dreamrealyou "won the battle" and yet you can't accept it, you demand philosophical agreement even though the intent is to give you everything you asked for
  138. dreamrealNow I'm gonna dig in my heels just to annoy you because you're annoying ME
  139. blueI didn't "win the battle", I don't want to configure EVERY INDIVIDUAL channel on discord to not use karma
  140. bluethis will still end up with me removing the otherwise very useful bot
  141. dreamrealBloody hell I SET IT UP SO THAT IT WOULD HAVE GLOBAL DEFAULTS
  142. bluewhich is just a pity
  143. dreamrealYou won the fucking battle SHUT THE FUCK UP ABOUT IT
  144. dreamrealNO. MORE.
  145. dreamrealI know you have like some kind of mental block that says you will never ever ever ever ever ever ever ever look at your premises and say "you know, the other guy might have a point, I'm carrying this on past the point of absurdity" so just make the decision that everyone else is wrong but you're going to have some grace and just sit in your superiority for a while in silence
  146. dreamrealin beit hillel and beit shammai you'd never accept the other to be considered as a viable alternative, whichever one you ended up in
  147. dreamrealbut this is not a good way to be
  148. bot[jottinger/bytecode.news] New issue #43: Production deployment: Docker Compose, reverse proxy, MTA, and documentation - https://github.com/jottinger/bytecode.news/issues/43
  149. dreamrealso just to clarify: #41 actually addresses global and per-channel defaults for operations. I haven't decided on a default for karma, specifically, yet, for reasons;
  150. dreamreal1. It's not all that important
  151. dreamreal2. the space separator actually does break a normal interaction. If I use tab completion *at the front of a line* I get a rational separator, and that separator gets discarded properly:
  152. dreamrealdreamreal: ++
  153. dreamrealhowever, if I hit tab *in a line* the separator does not show up:
  154. dreamrealdummies like dreamreal -- they are stupid [note: I used tab completion for my nick here]
  155. nevetdummies like dreamreal now has karma of -1.
  156. dreamrealnote: that's INTENDED to be a karma operation! And it is! But the flag would disable that.
  157. dreamreal(the reason my first karma operation didn't register is because my nick is intentionally ignored as a subject. "Dummies like dreamreal" is not a direct match, so it's not ignored.)
  158. dreamrealso issue 41 has a lot of configuration in it: system configuration for super-admins, oepration-level controls like "enable karma" and defaults (including, BTW, the emdash thing as an acceptance test), *and* operational controls at the provenance level, so you can control it for specific channels. A global configuration could be different than a channel configuration.
  159. blue15:26 < dreamreal> dummies like dreamreal DASHDASH they are stupid [note: I used tab completion for my nick here]
  160. bluethis is EXACTLY the point of contention RIGHT THERE
  161. blueI did NOT parse that sentence mentally as a karma operation DASHDASH but as a normal sentence
  162. dreamrealSure. You didn't. You're not the bot.
  163. blueyes, and the bot's interpretation is unnatural and dumb
  164. blueask ANYONE and he'd that you that's a normal sentence DASHDASH not a karma operation
  165. dreamrealI get it. Struggling to care, because it's a bot. It's not supposed to be natural.
  166. bluethat's not an argument. it's not supposed to be natural, it's supposed to be useful
  167. dreamrealDude, with all due respect, you do not want to say that. I've been on IRC for nearly 30 years.
  168. blueand ME since 95!
  169. bluethat's basically the same amoutn of time. you're not gonna get me on argument from authority here
  170. ChronosI'm one of the dummies too, and know that is 1/2 the battle!
  171. dreamrealSo you know the danger of selection. DOn't make that dare. You're saying "you can't find people to validate the behavior you just said you can validate through usage" and, uh, I can indeed validate that behavior through usage, which is why I made the assertion in the first place. You've made your point. You seem to be struggling to accept that others disagree even though you made your point
  172. dreamrealsuccessfully.
  173. dreamrealYou are being an asshat. Please stop.
  174. blueI'm not, but I'm gonna drop it not because I think I should, but because you're forcing me, note that
  175. dreamrealI'm definitely putting it up on my quotes board.
  176. ChronosPersonal anecdote: I've seen lots of IRC bots support the concept of karma, but have never, ever found the karma feature useful in any of them.
  177. ChronosTherefore, I'm not sure the current subject matters. ;)
  178. blueI don't find it that useful either. In my personal experience, karma should be indirect anyway, by using ^ following the person you agree with
  179. bluethat doesn't allow for karma for concepts, but who cares. the whole idea of hindu karma is about living beings, not concepts, anyway
  180. ChronosI guess it could be useful for determining things like, "Which of these two good options has the highest karma?" Check the karma of both, and off you go?
  181. blueyeah, except no one ever did that... looked up the karma value of two things on irc to determine a course of action
  182. bluehowever: karma for people could be interesting to map out the territory in a new channel
  183. ChronosI've never seen anyone do that either, though perhaps they queried the bot directly, rather than doing it in a main channel.
  184. blueit could indicate a matrix of acceptance/approval/merit that transcends ophood
  185. blueDASHDASH is useful
  186. bluein which case, it would be useful, because people on irc sometimes abuse ophood to argue from authority
  187. Chronosdreamreal: Is nevet intended as a "general purpose" IRC bot? Or is it more specific to Java specifically? Or computer programming languages?
  188. dreamrealit's for information systems. It's leaning towards programming because its users and authors tend to be programmers - thus the factoid systems have things like "urls" and "maven coordinates" as primary aspects. #java and javabot (and purl, from #perl, #python, and others) were primary inspirations.
  189. dreamrealbut purl and javabot are literally designed as infobots, and I see "infobot" as a second-order consequence.
  190. ChronosActually, hmmm... I would say the way karma currently works is actually somewhat incompatible with channels whose topic is programming languages, since the increment and decrement operators are somewhat common.
  191. ChronosFor example, you might show some example code: for (int i = 0; i < 100; i++) { /* do something */ }
  192. nevetFor example, you might show some example code: for (int i = 0; i < 100; i now has karma of 1.
  193. ChronosFor example, you might show some example code: for (int i = 0; i < 100; i--
  194. nevetFor example, you might show some example code: for (int i = 0; i < 100; i has neutral karma.
  195. Chronos(Just doing some clean up there.)
  196. dreamrealkarma, in this case, is a toy. And karma's been around in programming channels since the very early days of purl; yes, there are misfires like that. but since IRC isn't a conversation that *can be interrupted* it's generally been seen as an artifact and not something that really matters; you might as well complain that you're knee-deep in conversation when someone joins or parts a channel.
  197. dreamrealDon't bother cleaning up, there's no need.
  198. dreamrealkarma records are not *expensive* in any sense of the word.
  199. blue(except you can filter out parts/joins)
  200. dreamrealblue: okay, fine. Let's pretend you're not being officious: let's ignore parts and joins and splits; how about someone joins INVISIBLY and says "hi all, how's it going" in the middle of a conversation.
  201. ChronosJoins and parts are one of my pet peeves about IRC, because they're so frequent (almost amount to spam). Fortunately, my IRC client "collapses" all joins and parts.
  202. bluedreamreal: then that's a USEFUL tidbit of info. you've failed to demonstrate how that bot reaction is useful in any universe
  203. dreamrealOddly enough, blue, you just interrupted an exchange taking place between chronos and me - are you not offended at yourself?
  204. bluenope
  205. blueyou're equating horses to donkeys
  206. dreamrealBy your own metric you should be, donkey.
  207. ChronosI don't like outright filtering out joins and parts, because I don't like talking to people that have parted. So I typically ignore the collapsed joins/parts when "just browsing" a channel conversation, and pay more attention to them when I'm actively participating in a channel.
  208. bluethe bot repeating that isn't doing anything useful, by any metric
  209. dreamrealA lot of that is just an artifact of being on IRC.
  210. dreamrealhumans learn how it works, they adjust IT or what they expect, we all somehow survive, not being incinerated by information like four lines of joins/parts, or - as known in the bad old days when connectivity was apparently over a phone line over the atlantic - 50 lines of joins/parts.
  211. blueI feel at this point you've looking for reasons to justify this, and I'm not gonna change my mind, so this is going to be one of the sad rare moments we'll have to do the dumb modern thing of agreeing to disagree
  212. dreamrealTBH I don't even understand what the problem is: the issue exists, I'm going to address the behavior, you're still talking about it.
  213. * Chronos wishes IRC wasn't (still) "constant connection oriented," but totally understands why it (still) is.
  214. blueso will it be possible to deactivate it for an entire discord server, dreamreal?
  215. dreamrealChronos: slack is right there, buddy :D
  216. blueand who will control that, the server admin?
  217. Chronosdreamreal: Heh! I do use Discord, but I'm under no illusion that it won't keep walking down the enshittification path.
  218. bluethat's impossible, Chronos
  219. bluediscord was already created in a state of absolute debauchery
  220. ChronosHeh.
  221. dreamrealblue: I doubt it, because of the nature of discord connections: it's not "a discord server," it's discord. It might fall out of the provenance stuff, which is built off of URLs: I just haven't tried it yet.
  222. ChronosI'm a (happy) IRCCloud subscriber, which solves a lot (not all) of the "constant connection oriented" design.
  223. blueso how would I disable it for my entire disocrd server + one channel here? run my own nevet? that was what I was trying to avoid, also the code isn't open source atm
  224. dreamrealIt'll be controlled by admins; there're multiple levels of admins, but operations would be admins. The admins are NOT by provenance though.
  225. * Chronos is one of those rare people that doesn't mind paying for stuff (gasp!)
  226. blueya I don't mind paying for nevet either
  227. blueit if creates value, why not
  228. dreamrealblue: that's the thing; discord doesn't HAVE servers
  229. dreamrealit has guilds
  230. blueMEIN GOTT
  231. dreamrealyou connect TO discord and get the guilds
  232. blueit's the same thing, NO ONE SAYS gilds
  233. blueit's just hteir dumb technical docs use guild_id
  234. bluebut it's a discord server, in universal parlance
  235. Chronosblue: The recent ID / face scan stuff from Discord was a "good reminder" for a lot of people.
  236. dreamrealRight. I know what you mean, and I'm describing WHY it's possibly (POSSIBLY) difficult - it may fall out of the provenance mechanism, but I haven't tried it. We don't have "connect to this, and tha, and the other" in discord.
  237. dreamrealin IRC we do, in SLACK we do.
  238. blueChronos: yes. but also, you do need an id to get into an adult movie theatre, discord is just doing the same...
  239. blueyou also need an id to buy liquor or porn magazines, I never got the argument why those restrictions ought not to apply online
  240. dreamrealblue: in any event, you're still tilting at windmills: I do not know, because I have not tried, and specifying guilds in provenances is a DRAG, I hate it, and it's a consequence of how discord works
  241. bluedreamreal: ok use case. I want to use nevet, NOT deploy it on my own, and either disable the karma op entirely for my discord server and irc channel, or just the emdash thingy. will THAT be possible or not? simple yes no
  242. dreamrealI don't see a reason it ABSOLUTELY COULD NOT work with tiered permissions, but that's just work, and I haven't done it, and nobody's paid me to do it so I'll get to it when I get to it
  243. dreamrealof course
  244. dreamrealyes, a thousand times yes, and that's been the case since you raised the issue in the first place and I've said so
  245. bluebecause again, #41 talks about "per channel", which means I'd need to configure it for every discord channel on my server
  246. Chronosblue: I don't really have a problem with the "prove you're an adult to access adult spaces" idea in general, but when it comes to online/tech companies like Discord, I simply don't trust them to keep that kind of sensitive data secure.
  247. bluealternatively, it talks about "universal", and I'm not a nevet admin
  248. ChronosI'm not sure how many more hacks need to happen for people to understand they should never, ever share that kind of sensitive data, unless access is absolutely required.
  249. dreamrealblue: nevet isn't a PAAS :D
  250. blueChronos: so incidentally, I had this conversation in another channel with other people. the concern was the same -- why should we provide our ids to some online shady illicit websites
  251. nevetChronos: so incidentally, I had this conversation in another channel with other people. the concern was the same now has karma of -1.
  252. Chronosblue: When I go to the liquor store, an employee briefly glances at my ID — the details aren't stored on some computer system that can and will get hacked, eventually.
  253. Chronosnever is a bot that works for both IRC and Discord?
  254. bluemy idea was that you could purchase offline an gift card, in cash if you care, and then use it online
  255. bluea gift card*
  256. dreamrealChronos: yes, it is connected right now to slack, discord, and irc
  257. Chronosblue: In a nutshell: It's a security issue. It's simply not a good idea to share an ID or face scan with Discord, because it's not safe or secure, no matter how much BS they spew about it being safe.
  258. dreamrealand has a bridge set up to mirror a channel between irc and discord (post something on one, the other one gets the same content)
  259. blueChronos: yes, and my idea avoids that
  260. dreamrealChronos: nevet means "stream" and it's designed to be a multifaceted consumer and producer of information
  261. dreamrealagh, blue is correcting my craptastic hebrew: "sprout"
  262. Chronoss/never/nevet/
  263. Chronosblue: I'm somewhat confident The Powers That Be could "put together" the data points on that path and still expose your identity.
  264. dreamrealblue: #41 has been updated to capture specialization of configuration, so now if you can specify the guild for discord you can in fact generalize configurations across guilds
  265. dreamrealit's not coded yet (again, volunteer here) but the feature's captured
  266. ChronosIt's fine with me if some people want to take the risk. For me, the answer is easy: I won't share my ID or face scan. If that means I'm limited to the spaces I can talk — or even limited to IRC — so be it.
  267. dreamreallargely because when it was expressed it wasn't issued from on high
  268. Chronosdreamreal: Oh, very neat. Did you write nevet?
  269. dreamrealyes
  270. dreamrealthus the github for it is jottinger/bytecode.news :D
  271. ChronosVery neat. I like the idea of being able to link disparate chat systems as well.
  272. blueyes, that was my idea
  273. dreamrealthe mirroring was, yes
  274. Chronosdreamreal: Nice! :)
  275. dreamrealnevet's initial design was ALWAYS to connect to discord, irc, slack, mattermost, matrix, etc. etc., anything I could connect it to
  276. ChronosKind of like the bot version of Pidgin
  277. dreamrealmattermost and matrix are still "todo" - I only have one mattermost connection and there's no way nevet will legally be allowed to connect to it
  278. dreamrealyes, very much, although the point of nevet is information capture and not actual communication
  279. dreamrealone of the previous versions' features was "summarize what's been going on" via AI
  280. blueI'm an early adopter, I have nevet serving at one of my projects
  281. dreamrealit didn't analyze anything without being asked to, but the idea was that it would go back 100 lines on a given information stream, time delimited, and say "oh, man, that chronos guy is going OFF on how much he really likes ponies these days"
  282. blueonce it can reliably do github via webhooks, I'm gonna turn off the built-in discord thingy for that and replace with nevet's
  283. Chronosdreamreal: Information capture? You're one of them! You're working for The Man! ;)
  284. bluethen I would get my lifelong dream of informing both irc and discord at the same time
  285. dreamrealblue: incidentally, when I'm not fending off peoples' ridiculous requests via karma, I'm working on spinning up the UI - which is the MAIN blocker for github webhooks
  286. Chronosponies++ Ponies are awesome!
  287. nevetponies now has karma of 1.
  288. dreamrealonce the UI's up, webhooks get a lot easier
  289. bluewait what
  290. dreamrealChronos: for the record, I work for the man for real
  291. bluein what universe is the UI related to endpoints
  292. Chronosdreamreal: What are you using for the UI? If you don't mind saying.
  293. Chronosdreamreal: Given the owners of the company I work for, I probably do too, just indirectly.
  294. dreamrealblue: webhooks require exposed endpoints. The UI = exposed endpoints. nevet as it's deployed RIGHT NOW exposes NOTHING to the outside world outside of the connections it's using.
  295. blueI fear we have a massively disparate conception of UI
  296. dreamrealChronos: kinabalu wrote a UI in next.js, probably with claude or perplexity :D
  297. blueyes and it SUCKS
  298. blueobviously he should taken something else! not saying what
  299. dreamrealblue: "the ui" in this case is the blog. Right now as deployed, nevet exposes NO ports to incoming traffic.
  300. dreamrealblue: well, it's open source, you're welcome to contribute better... the endpoints are documented.
  301. blueif I send you a primate PR, you'll merge it? where would I put it?
  302. bluethere's currently just 'frontend' and it's that nextjs app
  303. Chronosdreamreal: Ah, neat. (I'm not personally anti-AI, so I have no problem with AI generated code — as long as it's been properly reviewed, of course.)
  304. dreamrealChronos: I just want the UI to work
  305. Chronos"primate PR" — love it! :)
  306. dreamrealblue: Hell, put it in primate-frontend. But I need to get the frontend deployed, first, because that means the basic services the front end NEEDS work. The goal is to have nextjs.bytecode.news, primate.bytecode.news, react.bytecode.news, struts.bytecode.news ... and bytecode.news routes to whichever one happens to be best.
  307. bluek, I'll see what I can do. you just need a blog for now?
  308. dreamrealThat way, if ANYONE goes "hey, I know wicket really well, why isn't the front end in wicket" they can write one in wicket and have a 1:1 comparison point.
  309. dreamrealThe goal is to support service-blog, yes.
  310. ChronosOh, I thought "primate PR" was a joke about it being a PR made by a person rather than an AI — did I interpret that wrong?
  311. dreamreal~primate
  312. dreamrealprimate
  313. dreamrealgrrr
  314. dreamrealfactoids got reset, hold on
  315. ChronosI still have a pretty big factoids DB from when I was an op in EFNet #c in the 1990s and running channel bots :)
  316. dreamrealprimate=<reply>Primate is an opinionated, largely language-neutral web framework. It supports multiple front ends, backends, and runtimes, with a tendency towards to the javascript ecosystem.
  317. nevetok, dreamreal: updated primate.
  318. dreamrealprimate.url=https://primate.run/
  319. nevetok, dreamreal: updated primate.
  320. dreamrealprimate.seealso=react,angular,vue,svelte,javascript,typescript,webassembly
  321. nevetok, dreamreal: updated primate.
  322. dreamrealprimate
  323. nevetPrimate is an opinionated, largely language-neutral web framework. It supports multiple front ends, backends, and runtimes, with a tendency towards to the javascript ecosystem. URL: https://primate.run/ See also: react, angular, vue, svelte, javascript, typescript, and webassembly
  324. dreamrealreact=<reply>React is a typescript web crap thingamabob that dreamreal avoids like the plague because it's UI.
  325. nevetok, dreamreal: updated react.
  326. dreamrealprimate
  327. nevetPrimate is an opinionated, largely language-neutral web framework. It supports multiple front ends, backends, and runtimes, with a tendency towards to the javascript ecosystem. URL: https://primate.run/ See also: react, angular, vue, svelte, javascript, typescript, and webassembly
  328. dreamrealhmm.
  329. dreamrealI think we finded a bug!
  330. dreamrealChronos: if you have an old DB of factoids, I'd be happy to migrate useful bits out
  331. dreamreal(It's supposed to show "~react" there because it's an existing factoid, in teh seealso section.)
  332. ChronosAwww. And here I thought "primate PR" was so clever!
  333. dreamreal:D
  334. Chronosdreamreal: The old EFNet #c factoid DB is... low quality... but I can dig it up
  335. dreamrealit may not be worth it, plus it's C
  336. blueChronos: Primate is my framework, I'm the author
  337. ChronosAnd, oh my goodness, was maintaining a big EFNet channel in the 1990s+ difficult. EFNet never did give us proper tools for channel administration.
  338. dreamrealfoo
  339. blueI just usually don't capitalise its name when I talk about it
  340. dreamrealfoo=bar
  341. nevetok, dreamreal: updated foo.
  342. Chronosblue: Oh, neat!
  343. dreamrealfoo.seealso=baz
  344. nevetok, dreamreal: updated foo.
  345. dreamrealbaz=bletch
  346. nevetok, dreamreal: updated baz.
  347. dreamrealfoo
  348. nevetfoo is bar. See also: baz
  349. dreamrealfoo.seealso=baz,quux
  350. nevetok, dreamreal: updated foo.
  351. dreamrealfoo
  352. nevetfoo is bar. See also: baz and quux
  353. blueI honestly have no idea what he did there with nextjs... it's sending requests to the actual backend from the frontend? that seems awfully ineffective
  354. dreamrealThat's supposed to be "~baz and quux"
  355. dreamrealblue: he probably had perplexity or claude do it
  356. blueI'm just gonna pretend I didn't see that code and ask you what you expect of a UI, dreamreal
  357. bluebecause I feel that code is a dumpster fire
  358. dreamrealI dunno, you UI people are ridiculous and bonkers, I just wants it to work
  359. bluebeyond being in nextjs, that is
  360. dreamrealblue: I'd ignore the code, the endpoints are documented (and there's openapi generated for it too)
  361. bluealrighty. for your information, I'm likely to proxy it to /api or so
  362. dreamrealdon't care as long as I know how to deploy it
  363. bluethat is generally of no concern of yours, but it allows the actual backend to not be hardcoded into the frontend paths
  364. dreamrealIf you have a requirement that changes service-blog, that's fine too, I just need to know and teh documentation HAS to be kept up to date
  365. dreamrealthis is a new API, so it's not expected to be hardened yet
  366. blueI'm not gonna touch the openapi def just work against it. if it changes, it changes
  367. blueI'll probably version it though
  368. bluethat would be nice, would it not?
  369. dreamrealI'm just saying if you find holes, that's not going to surprise or offend me
  370. dreamrealdepends on how: if you're going to version it, it'd be mapped as a selector
  371. bluedo you have a /version or so?
  372. dreamrealas a concept, I'm fine
  373. dreamrealno
  374. bluenvm, I'll look it up myself
  375. bluemight be a case of YAGNI
  376. bluehttps://github.com/jottinger/bytecode.news/blob/main/docs/api-reference.md
  377. bluethis is all I need to know?
  378. dreamrealif we version the endpoint, it's going to be with header versioning
  379. dreamrealthat doc is supposed to be, yeah
  380. bluek
  381. bluedreamreal: where is the openapi yaml/json?
  382. dreamrealIt's generated live on deployment, I don't store it, I need to do that, huh
  383. bluej
  384. bluek*
  385. bluewell, it's time to revive the openapi module, dreamreal
  386. dreamrealrevive...?
  387. dreamrealopenapi is baked in, it just doesn't generate an artifact, because openapi is dumb
  388. blueyes. I never really finished it. the idea is to do `npx primate openapi defile.yaml --target=python`, and it generates you a client in the target language. default would be TS
  389. nevetyes. I never really finished it. the idea is to do `npx primate openapi defile.yaml now has karma of -1.
  390. bluedeffile.yaml*
  391. dreamrealyeah. kinabalu actually has some code somewhere that generates the openapi artifact as part of test output, that's actually really useful and I need to integrate it.
  392. bluethe client would be generally typed. so client.posts.year(...).month(...).slug(...).comments.get()
  393. blue-> would call `GET /posts/{year}/{month}/{slug}/comments` using the bearer token the client was init'd with
  394. bluedepending on the openapi yaml, path params can be typed (numbers). that would be translated to a type in the target language, if the language is typed, that is
  395. blueI mean number | string | array, etc.
  396. blueI imagine that since java is typed, the openapi def would include that
  397. blueand we can actually runtime-verify it in TS, which is superneat
  398. dreamreal*nod*
  399. bot[jottinger/bytecode.news] New issue #44: Factoid see-also summary does not decorate known factoids with ~ - https://github.com/jottinger/bytecode.news/issues/44
  400. * blue checks if kotlin has a wasm target
  401. blueoh wow, it even has wasi, that's sweet
  402. dreamreali's an utter drag to work with, though
  403. blueneeds gradle?
  404. bluethat's fine by me
  405. dreamrealno, the runtime libraries are different
  406. blueapparently they have a node and deno examples
  407. blues/a//
  408. dreamrealI use kotlin in the JVM so I have the full JVM ecosystem - the multiplatform kotlin stuff can't rely on the JVM, so there's a whole OTHER platform-neutral library ecosystem
  409. bluedreamreal: btw: a sed operation in nevet would be awesome
  410. blueah, gotcha
  411. dreamrealsed would be easy, too, file an issue, but mein Gott is it noisy :D
  412. dreamrealhmm, maybe that's another thing: a throttle
  413. dreamrealrunning a test now to work out the factoid fix AND store openapi output in the repo
  414. dreamrealheh, year, month, date are strings in the open api :D
  415. dreamrealI know why, but it's still funny
  416. bot[jottinger/bytecode.news] New PR #45: Fixing factoid expression and adding openapi artifact - https://github.com/jottinger/bytecode.news/pull/45
  417. * nevet joined #nevet
  418. * 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
  419. dreamrealfoo
  420. nevetfoo is bar. See also: ~baz and quux
  421. dreamrealWorking!
  422. dreamrealbaz
  423. nevetbaz is bletch.
  424. dreamrealquux
  425. dreamrealperfect.
  426. dreamrealfoo.forget
  427. nevetok, forgot foo.
  428. dreamrealbaz.forget
  429. nevetok, forgot baz.
  430. dreamrealquux.forget
  431. dreamrealblue: main now has docs/openapi.json
  432. bluethank you!
  433. dreamrealthe guy who wrote the nextjs frontend showed the way :D
  434. bluethis is REALLY nice: schema: { type: string, format: uuid }
  435. bluethis means the generated client can *runtime-verify* that the given param is a valid uuid
  436. bluethe server will obviously also have its json parsing, but this should fail early
  437. dreamrealuuidv7 internally, too, BTW
  438. blueyeah, technically this isn't ocmmunicatable via openapi I think
  439. bluethe validation will be against a common subset of v4 and v7
  440. bluethey're very similar, anyway
  441. bluethey differ mostly in how values are created -- not their format
  442. nevetthey differ mostly in how values are created now has karma of -1.
  443. dreamrealyeah, that's why I said internally :D you can't examine a uuidv4 and v7 and tell them apart without knowing their relationship
  444. bluethe only difference is the 13th character: it's 4 respectively 7
  445. bluedreamreal: you can, as I just said
  446. bluethe 13th character is set
  447. dreamrealIs it? oh, nice
  448. bluev4: e4ddfa5d-f953-42a9-8f38-f58f59569e87
  449. bluev7: e4ddfa5d-f953-72a9-8f38-f58f59569e87
  450. dreamrealI don't pay attentin to the crap you say!
  451. dreamrealbut yeah, I guess that makes sense
  452. blueso to validate both, you need to allow 4|7 for the 14th character
  453. dreamrealnot really relevant for downstream uses, though, I don't think nevet accepts external UUIDs to be generated
  454. blueit's not about accepting, it's about verifying it before it goes out to nevet. if it's not a valid uuid, there's no reason to send the request
  455. dreamreal*nod*
  456. bluedreamreal: I still got the openapi collection running, e.g.: https://openapi.primate.run/spec/anthropic.json
  457. blueI'm gonna add nevet.json.. or maybe I'll call it bytenews.json ?
  458. dreamrealbytecode.news is the codebase, nevet's just one instance
  459. bluehow would you generalyl call the openapi def file?
  460. dreamrealWhat do you mean? Like, at what URL would it be exposed in a running instance?
  461. bluethere's quite a few of them:
  462. bluehttps://openapi.primate.run/manifest.json
  463. dreamreal${servername}/v3/api-docs is the endpoint that's exposed
  464. blueI want to add an entry for your stuff
  465. blueI'm just looking for a proper name for it
  466. dreamrealI'd call it bytecodenews if it can't handle a period, or bytecode-news
  467. blueit's generally quoted, so dot would be ok. I can also just simply call it after the github repo name, so jottinger/bytecode.news.json
  468. dreamreal*nod*
  469. bluehm
  470. bluedo you intend to open the repo at some point? I just realised this isn't gonna work with a private repo. I might need to put in the file manually
  471. dreamrealProbably; streampack is, I guess I was thinking I'd make sure this was more hardened than it is before I opened it up
  472. blueI can hardcode it for now
  473. dreamrealthe log sanitization has already been put in, and that was a pretty big aspect of that
  474. dreamrealbut I need to make sure the rest of it's good too
  475. blueheh: (node:149949) [TAG_RESOLVE_FAILED] YAMLWarning: Unresolved tag: tag:yaml.org,2002:float at line 21392, column 28:
  476. blue(this is unrelated to your openapi, it's someone else's)
  477. dreamrealI'm working on the deployment stuff, so you will eventually be able to spin up a local instance with docker compose with working backend and db
  478. dreamrealthe front ends will be deployed in docker, too, eventually
  479. bot[jottinger/bytecode.news] New issue #51: Deployment guide documentation - https://github.com/jottinger/bytecode.news/issues/51
  480. bot[jottinger/bytecode.news] New issue #50: Nginx config examples for multi-frontend deployment - https://github.com/jottinger/bytecode.news/issues/50
  481. bot[jottinger/bytecode.news] New issue #49: Backend Dockerfile and docker-compose service - https://github.com/jottinger/bytecode.news/issues/49
  482. bot[jottinger/bytecode.news] New issue #48: Frontend Dockerfile and docker-compose service - https://github.com/jottinger/bytecode.news/issues/48
  483. bot[jottinger/bytecode.news] New issue #47: Externalize Next.js API rewrite target - https://github.com/jottinger/bytecode.news/issues/47
  484. bot[jottinger/bytecode.news] New issue #46: Externalize CORS allowed origins to env var - https://github.com/jottinger/bytecode.news/issues/46
  485. bot[jottinger/bytecode.news] New PR #52: Updating CORS - https://github.com/jottinger/bytecode.news/pull/52
  486. dreamreal~glot.io.url=https://glot.io/new/java
  487. dreamrealglot.io.url=https://glot.io/new/java
  488. nevetok, dreamreal: updated glot.io.
  489. dreamrealglot.io
  490. nevetURL: https://glot.io/new/java
  491. dreamrealideone.url=https://ideone.com/
  492. nevetok, dreamreal: updated ideone.
  493. dreamrealideone.seealso=glot.io
  494. nevetok, dreamreal: updated ideone.
  495. dreamrealglot.io.seealso=ideone
  496. nevetok, dreamreal: updated glot.io.
  497. dreamrealglot.io
  498. nevetURL: https://glot.io/new/java See also: ~ideone
  499. dreamrealglot.io=an online code runner, much like a simple IDE, useful for demonstrating simple code.
  500. nevetok, dreamreal: updated glot.io.
  501. dreamrealideone=an online code runner, much like a very simple IDE, useful for demonstrating simple java code.
  502. nevetok, dreamreal: updated ideone.
  503. dreamrealglot.io
  504. nevetglot.io is an online code runner, much like a simple IDE, useful for demonstrating simple code. URL: https://glot.io/new/java See also: ~ideone
  505. dreamrealChronos: ^^^
  506. dreamrealChronos: compare this to how javabot does it :D
  507. dreamrealit's more verbose but MUCH better targeted
  508. dreamreal...and since nevet isn't tied to IRC, if you were talking to it over slack or discord, you can now do !glot.io and get the factoid
  509. dreamrealfactoid search runner
  510. dreamrealhmm, I need to remember how to do the searches
  511. dreamrealsearch runner
  512. nevetSearch for 'runner' matched: ~glot.io and ~ideone
  513. dreamrealwell, THAT was simple :D
  514. dreamrealsearch ide
  515. nevetSearch for 'ide' matched: ~glot.io, ~ideone, and ~pep 3
  516. dreamrealidea=<reply>IDEA 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.
  517. nevetok, dreamreal: updated idea.
  518. dreamrealeclipse=<reply>Eclipse is one of the "big two" java IDEs, and is generally free, although there are commercial variants. Built on OSGi, it's got an incredibly large ecosystem.
  519. nevetok, dreamreal: updated eclipse.
  520. dreamrealidea.seealso=ide,eclipse
  521. nevetok, dreamreal: updated idea.
  522. dreamrealeclipse.seealso=idea,ide
  523. nevetok, dreamreal: updated eclipse.
  524. dreamrealidea.url=https://jetbrains.com/idea
  525. nevetok, dreamreal: updated idea.
  526. dreamrealeclipse.url=https://eclipseide.org/
  527. nevetok, dreamreal: updated eclipse.
  528. dreamrealnetbeans.url=https://netbeans.apache.org/
  529. nevetok, dreamreal: updated netbeans.
  530. dreamrealnetbeans.seealso=ide,eclipse,idea
  531. nevetok, dreamreal: updated netbeans.
  532. dreamrealnetbeans=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.
  533. nevetok, dreamreal: updated netbeans.
  534. dreamrealnetbeans
  535. 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
  536. bot[jottinger/bytecode.news] New PR #54: Updating docker-compose for development porpoises - https://github.com/jottinger/bytecode.news/pull/54
  537. bot[jottinger/bytecode.news] New PR #53: Fixing Next.JS base url - https://github.com/jottinger/bytecode.news/pull/53
  538. dreamreallots of fixes so far today, none too far reaching but they're important
  539. bluedreamreal: `client.posts.year(2020).month(1).slug("hi").comments.get();`
  540. bluethat's the shape in TS. year and month will unfortunately be verified as strings. what type are they in the kotlin code?
  541. blueI expected "number" in the openapi... but it's "string"
  542. bluewhere is the path mapping located in the code, could you point me to it?
  543. dreamrealhttps://github.com/jottinger/bytecode.news/blob/69dda17cd6e4188bc16371bb4c4c8cf26e17efa6/service-blog/src/main/kotlin/com/enigmastation/streampack/blog/controller/PostController.kt#L79
  544. blueah
  545. blueservice-blog/src/main/kotlin/com/enigmastation/streampack/blog/controller/PostController.kt: @GetMapping("/posts/{year}/{month}/{slug}")
  546. blueya, thx
  547. dreamrealThis API is very raw and very new so if we need to adjust it we can
  548. dreamrealI'm not opposed to migrating that to a proper numeric type
  549. dreamrealand honestly... where's the day
  550. blueyes. personal take: make year, month and day numeric.
  551. bluemy openapi client will benefit from it
  552. dreamrealhold on, investigating
  553. blueI'm fine with Int. the outputter will likely make a javascript `number` of it, which is fine. openapi v3 technically has a min-max thingy, which years and particularly months and days could immensely benefit from
  554. bluemonths should definitely be min 1 max 12
  555. dreamrealhold on, still investigating impact
  556. bluedepending on how kotlin parses Int, you could still accept 01
  557. blueor a bespoke type, would be perfect
  558. dreamrealgive me a few minutes, yeesh
  559. dreamrealI can have this fixed real soon but I need to make sure the impact is managed
  560. blueit's not my fault you're SLOW!
  561. blue(to anyone else: this is in jest. dreamreal often prides himself on reading super fast, and will expect me to finish reading things he wrote within quantum time)
  562. dreamrealI'm almost done, JACK HOLE
  563. blueclock's tickin
  564. dreamrealcompiling for tests now, and need to do a full compile to regen the openapi endpoints too
  565. dreamrealbut that's a good catch
  566. dreamrealI noticed it earlier but it's UI-related so I didn't REALLY care, but I figured if it was significant enough someone else would pipe up and tell me to care
  567. blueI AM that someone
  568. dreamrealyes
  569. bluelooking like I'm snugging in into the shammai role here
  570. dreamrealYou've definitely never left the shammai role, except shammai at least tried to understand hillel some
  571. bluego on. tell me that every bride is pretty on her wedding day EVEN IF SHE'S UGLY
  572. bluehave me roll my eyes
  573. dreamrealIt's one thing to pretend reality is malleable, it's another thing altogether, and a negative one, to bother SAYING "you know she's a troll, right?"
  574. blueoh, that's below me
  575. blueI'll still have that thought, likely. which is probably just as bad, thoug
  576. bluethough*
  577. dreamrealyes, and that's the point hillel was making
  578. blueyes
  579. dreamrealokay, main is updated, as is the openapi spec
  580. blueSWEET
  581. dreamrealearliest publication year is set to 2007, because I'm thinking I might migrate some old articles over from the java channel blog
  582. dreamrealand if this is still running in the year 3000CE I'll take the maintenance hit of updating the schema
  583. dreamreal"great-great-great-great... something grandpa has had us running that VPS for freaking *centuries*."
  584. bot[jottinger/bytecode.news] New issue #57: Multi-site blog hosting: shared infrastructure, per-site content - https://github.com/jottinger/bytecode.news/issues/57
  585. bot[jottinger/bytecode.news] New issue #55: Use integral types for year/month path variables in blog endpoints - https://github.com/jottinger/bytecode.news/issues/55
  586. bot[jottinger/bytecode.news] New PR #56: Updating blog endpoints to provide proper types for slugs - https://github.com/jottinger/bytecode.news/pull/56
  587. blue@Schema(minimum = "2007", maximum = "3000") year: Int,
  588. bluesweet tuches!
  589. bluenice, the openapi exporter got it too:
  590. blue{ type: "integer", format: "int32", maximum: 3000, minimum: 2007 }
  591. bluedreamreal: you know what this means, right?
  592. blueit means I can translate this to a pema schema, so we get REAL runtime-validation!
  593. blue-> p.i32.min(2007).max(3000)
  594. bluenow a client tries to do this: client.posts(2006). BAM, we error out even BEFORE we continue!
  595. blueactually client.posts.year(2006), but you get the point
  596. blueclient gets ParseError: value should be minimum 2007, got 2006
  597. blue*no request goes to server*
  598. dreamrealyeah, for all 4 requests that prevents :D
  599. dreamrealblue: did you see 57?
  600. * jreicher joined #nevet
  601. bluedreamreal: not yet. I'm formulating a proposal for the openapi client for primate. will do shortly
  602. bot[jottinger/bytecode.news] New PR #58: fix/55 integral types for blog slugs - https://github.com/jottinger/bytecode.news/pull/58
  603. * nevet joined #nevet
  604. * 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