Community
Chat Logs
Friday, February 27, 2026
- * skillbot joined #primate
- * skillnews joined #primate
- * jreicher joined #primate
- dreamrealfeed subcribe https://primate.run/blog.rss
- dreamrealfeed add https://primate.run/blog.rss
- nevetError: No RSS/Atom feed found at https://primate.run/blog.rss
- * nevet joined #primate
- * blue!~blue@user/blue changed the topic to: https://primate.run | this channel is mirrored to the Primate discord, channel #irc
- dreamrealfeed add https://primate.run/blog.rss
- nevetAdded feed "Primate Blog" with 20 entries
- dreamrealfeed subscribe https://primate.run/blog.rss
- nevetSubscribed to "Primate Blog"
- dreamrealblue: there you go
- bluethanks, dreamreal
- dreamrealblue: I was thinking of publishing the backend rest services to rest.bytecode.news, which would mean that I could actually handle github updates live instead of polling for them
- dreamrealand that would give UIs a consistent thing to hit, but it means that I need to harden some aspects of the services while I'm at it
- blueI'm... not sure why that is the case; because you can't do it without a universally reachable url?
- blueanyway don't call it REST: call it api, would be my call. rest exposes the technically implementation, which is irrelevant
- dreamrealtrue enough
- dreamrealbut what do you mean: why is that not the case for... what?
- dreamrealif we have api.bytecode.news, github can indeed post updates to a consistent URL
- dreamrealand then we can stop polling github for updates
- blueyes that was my point. if you don't 'expose' the backend in some universally reachable way, you can only do polling
- dreamrealI feel like we're saying the same things but different
- blueyes
- dreamrealso let's reset: my thought is, get api.bytecode.news online ASAP. Since it allows anonymous posts to the content, that means we need to make sure that *write* operations are constrained where possible and have *limits* where constraints aren't possible, like content posting
- bluedreamreal: idea; if you have api.bytecode.news, then... other subdomains feel a bit overengineered. I'm truly questioning the usefulness of primate/nextjs here vs just a frontend
- bluewhy the indirection? what's the value?
- dreamrealblue: https://enigmastation.com/2014/07/09/repost-some-of-what-id-wanted-to-do-for-theserverside/ is the mindset I had
- dreamrealIgnore the JCR bit, JCR is great but effectively dead and gone
- dreamreal(not really, but it's a lot for the value it would provide here)
- blueyeah I'm down to frotnends now
- blueI read REALLY fast -- faster than you :P
- dreamrealit's not a race, newsom
- blueyeah the problem still remains the indirection. a react.bytecode.news might make sense... I'm not sure nextjs/primate
- dreamrealmy thought was that most users would use bytecode.news or www.bytecode.news
- dreamrealso whatever fulfilled the interface requirements best would be that
- blueI understand that. I'm just still convinced about having two backends, especially if you have api.bytecode.news
- bluenot convinced*
- bluebut maybe.. hm.
- dreamrealYeah... I ... don't know what the "other backends" would be
- dreamrealThere's a design question here I'm not qualified to answer
- blueso there's a real tension here, and the tension is there. normal web app applications typically don't use APIs, at least directly
- bluethey use bespoke paths, which might or might not compose over APIs
- blueyou follow?
- blueapi.bytecode.news is interestingly not for a web app... but for someone writing clients for nevet
- blueinteresting*
- blueof course, a web app COULD use it. but it would typically also access a DB in a more direct fashion
- bluethings like transactions... are harder to realise if you have a backend solely relying on an API
- dreamrealI mean... this is just AJAX stuff
- dreamrealI'm saying that front ends would use AJAX to hit the api
- blueI realise this is ajax stuff. but say I want to have a route bunlding SEVERAL API calls in one. how do I transactionalise this?
- dreamrealAdmittedly I'm probably BADLY out of date...
- dreamrealI don't know! But the API endpoints were designed to BE transactional endpoints - you wouldn't normally WANT to bundle them separately
- bluein which case, an extra backend such as nextjs/primate is an indirection layer with zero added value
- dreamrealunless the front end NEEDED it, I suppose, gut ... again, this is not my area of expertise at all
- dreamrealI had to look up the term AJAX to remember it!
- blueyeah, we don't use that anymore. just REST/JSON
- bluebut let me give you an example
- dreamrealsure
- blueDELETE /admin/comments/{id}
- dreamrealokay?
- bluesay the frontend has the ability to select several comments for deletion. the primate route would get the ids. what does it do now?
- bluein a normal application, this would be transactionalised
- bluenow you COULD say, I'll just create another endpoint where you can delete several comments at once, fair
- bluebut there are other cases that are less straightforward
- dreamrealah. Right. Okay, I'd say that THAT BEHAVIOR is actually out of spec. And if behavior like that SHOULD BE in spec, we need to create a backend endpoint for it. That's part of why I want to get the API public and out there as soon as possible.
- blueI guess the point I'm trying to make is... building web apps on top of APIs is possible, but typically, you do need transactions to give you the bespoke abstraction level that isn't available over API call composition
- blue"I want to delete the comments but also inform the user about it, and I want it as a binary operation -- either everything or nothing"
- dreamrealyeah, well, I've been trying to design the API such that the response to that is "cool story bro the API is right there." And the other thing about nevet is that it's VERY literally designed on a messaging platform: you could, in fact, connect to the underlying mechanisms if you had access and do EXACTLY THAT.
- * phaleth joined #primate
- dreamrealThe API isn't designed to be composed; it's designed to be "these are the things you can do," not elements of transactions *but transactions*.
- blueyeah I understand
- bluethat however, makes frontends very rigid
- blueand maybe that's intended
- dreamrealit is, for better or for worse
- bluebut frontends aren't supposed to transport API/backend logic 1:1
- dreamrealwell, there are different design philosophies, and tradeoffs are definitely involved
- dreamrealI didn't want the ability of a front end to work to depend on how well a given developer could compose operations
- dreamrealthe operations work or they don't, so the front end's "works or not" is based on whether it interacts with those sets of operations
- blueso from this perspective, I *think* having a secondary backend is totally an overkill
- bluethat is: rather than using primate, I would be taking your reference and rewriting it in svelte or react
- dreamrealthe front end, in the end, is an ingress/egress adapter itself: the controllers *quite literally* translate the HTTP data into operational types, and these get fed into the event system, *just like* IRC strings do, discord, slack. It's all the same engine. the factoid operations work over HTTP just like they do IRC - it's *very* literally the same code, there's not an HttpFactoidOperation, just a
- dreamrealGetFactoidOperation that knows how to translate strings into factoid requests (for stringly communications) and how to respond to factoid requests
- dreamreal*nod*
- bluebut also, this might result on having to reiterate on the API quite a lot; see comments example: if you want to be able to delete several comments, sending n API calls is a nightmare
- blueresult in*
- blueany composed operation in the frontend that has no API correspondence... would trigger either "no, you can't do that" or "wait, I need to add this to the API"
- blueI'm telling you from experience this COULD become rather unpleasant
- bluedifferent proposition:
- dreamrealOh, you're not wrong, at all. But again, this is why I was trying to involve people with UI experience early and often, and I even said "please give me feedback" because we expect the surface to mutate until it fits the needs well
- bluethe primate backend is a FULL-STACK app *using* nevet. in which case, it has its own database. but there might be a lot of data repetition involved
- blueso the primate backend/app can compose however much it wants, using nevet API primitives
- dreamreal*nod* And I'd say that as a strategy, that could *work* but would be suboptimal - a front end should NEVER EVER talk to nevet's database, because the fact that nevet uses postgresql is *incidental*. I could easily swap it for an IMDG (and as soon as I convince gigaspaces to give me a license, you better believe I'm doing it) or mongodb.
- blueit's more than that. primate would enterain its own db, completely separated from nevet's pgsl
- blueentertain*
- dreamrealif it did so, that'd be fine. I wouldn't care.
- dreamrealThe key is that they'd be SEPARATE systems, and the system of record would be nevet.
- bluebut I'm not a super huge fan of data duplication
- dreamreal(I used to work for gigaspaces; nati shalom is a good friend.)
- dreamrealSo is gil tene, actually
- blue.ils?
- bluethey do sound like it
- dreamrealaye
- bluemaybe the golden path is the primate app acting as a sort of medial cache here
- dreamreal... for primate, sure
- bluefor data
- dreamrealLike I said, my goal was to provide the system of record and the API as a baseline; how it's used isn't important to me AS LONG AS nevet remains the system of record
- blueI'd need to think how to make that works, but things like posts/comments would be cached
- bluework*
- bluedeleting them.. well, there it becomes hard because you need the source of truth for that
- blueso for example
- dreamrealWell, primate could do that as a transaction: cascade each one as an op through nevet in order. failures would radiate outward depending on what they were (not found isn't the same as "could not delete.") But if the API *needs* a "delete multiple things" then maybe that's a need that gets addressed.
- blue`GET /posts/search` this could be well cached by the primate database, with periodic resync
- dreamrealI'd think search would be one of those things caching would serve LEAST, but eh
- dreamrealthe way I see it, primate's local DB would be a cache of *actual known data* - like, hit a slug, that's a known thing, you can cache that (and hope it doesn't get updated after caching).
- bluewell, consider this
- bluefor me as an app developer, doing this is ideal: `const posts = await Post.find({ where: ... });`
- bluethis is typically a primate ORM query
- blueI can build an interface around it, with querying for certain aspects for a post, limiting, criteria, etc.
- bluenow, one things I've been working on which would be already beneficial is the generation of the openapi client
- bluein which case, I'd already have at least a client that can do API calls, as documented
- blueso if the operation id is searchPosts, it'd be `client.searchPosts` instead
- bluethis call, however, is EXPENSIVE. it's an API call
- blueit's possibly also not very flexible, so maybe doing a GET posts periodically instead, and caching it in my own db, is faster
- phalethdoes that call enforce pagination?
- dreamrealin the openapi call, yes
- bluethere is a `page` param, yes
- bluein both GET posts and GET posts/search
- phaleththen can put max limit to the page size in order to not make it expensive
- bluethe expensive part is the extra web request
- bluethat means every primate frontend<>backend request is essentially two web requests
- phalethwell, that's the problem of the web
- bluealso, if I ever wanted to stream posts... or dynamically update the page..
- phalethprovide bson API or some sort of gRPC, but that's all you can do
- phalethcause there are two big problems in programming, and you can avoid the second one: cache invalidation problem
- blueyeah I thought of gRPC or json rpc, but currently nevet is a simple JSON api, and there's charm in that simplicaition
- blueand yes, cache invalidation is an absolute dumpster fire catastrophe, I 100% agree
- bluebut I'm worried about performance, perhaps prematurely here
- bluemy mind says: "if there's an API, and the API is all the composition we get, why not query it directly then? what's the use for a primate backend?"
- bluejust issue `fetch` directly to api.bytecode.news and be done with it. no real need for primate
- phalethin any case we can always employ memcached or something like that but only when that starts making any sense, but I'd not worry even if there's traffic already
- phalethof which there is currently none
- blueya
- dreamrealew
- dreamrealmemcached
- dreamrealew
- bluemaybe I'm chasing imaginary ghosts
- dreamrealew
- dreamrealmemcached--
- nevetmemcached now has karma of -1.
- dreamrealwhat a POS
- dreamrealmemcached--
- nevetmemcached now has karma of -2.
- bluebut APIs aren't built for performance... they're built for inter-app communication
- phalethfor sure one can shoot themselves in the foot with memcached, but again avoid the second big problem of programming if possible
- blueyou didn't stay the first one
- phalethwhat you can do is make the application layer scalable by not storing sessions server side
- bluestate*
- phaletheh
- phalethof course it's naming, can't solve that one
- blueah. thought you'd say rust
- blue:P
- phalethheh
- bluewhich btw
- blueew
- bluerust
- blueew
- blueew
- bluerust--
- nevetrust now has karma of -1.
- bluewhat a PON
- bluerust--
- nevetrust now has karma of -2.
- bluedone!
- dreamrealkarma chronos
- nevetchronos has karma of 3.
- dreamrealnevet's karma database still isn't old enough to decay yet :D
- bluetrue
- dreamrealkarma decays so "old karma" affects you less than new karma
- bluerust--
- nevetrust now has karma of -3.
- blue*patpat* good boy nevet
- dreamrealnevet is in the "ignore list" for karma automatically, too :D
- bluephaleth: dreamreal had a cool suggestion earlier: https://github.com/primate-run/primate/issues/250
- nevetSupport for HEAD · Issue #250 · primate-run/primate
- bluewhich I'm probably gonna add to .37
- blueas an opt-in config option: http.autoHead: p.boolean.default(false)
- blueoh man I HATE camelcase
- phalethyeah, web is broken when services respond with 404 on HEAD requests
- blue16:45 < phaleth> of course it's naming, can't solve that one
- blue+1
- blueI need to update the config page
- bluehttps://primate.run/docs/configuration
- bluehttps://github.com/primate-run/primate/blob/master/packages/core/src/private/config/schema.ts
- bluethose aren't synced
- blueyou know what, maybe I should just add jsdocs atop that and general that page automatically
- bluegenerate*
- bluebecause I know I will never remember to update the docs whenever I add or remove a config option
- phalethyeah, clankers are getting confused now
- bluethis is another case against ai, true
- blueemergent technology is practically useless
- blueso everyone just regenerates old, outdated code
- phalethwith the same old bugs
- bluewe had it earlier with nevet, I was querying it for an HTTP RFC, it gave me an old, obsolete one instead of the newer one
- blueit's almost like AI hinders progress
- blueit will give you reliable info about express, but garbage about primate
- phalethAI straight up hinders progress
- bluedreamreal: how far are we from nevet informing us here in the channel about issues, issue comments, PRs, commits and commit comments occuring on GH?
- dreamrealif it can poll, about two minutes
- * nevet joined #primate
- * blue!~blue@user/blue changed the topic to: https://primate.run | this channel is mirrored to the Primate discord, channel #irc
- dreamrealyeah, webhooks needs the api.bytecode.news
- blueok, I'll wait for that then
- bluethose can be reliably tested, btw
- bluein the webhook conf screen ongh
- blueon gh*
- bluethere's like a test event
- bluedreamreal: https://github.com/terrablue/gpbot/blob/master/routes/index.js
- blueif you need reference, here is how gpbot used to do it. I only added the events I was interested in
- phalethlast night at the exact same moment 47.7 clankers have been misled https://images4.imagebam.com/2e/60/e5/ME1AZ46G_o.png
- bluewhich was release, issues, push, commit_comment and ping
- bluephaleth: LOL
- * nevet joined #primate
- * blue!~blue@user/blue changed the topic to: https://primate.run | this channel is mirrored to the Primate discord, channel #irc
- bluehttps://github.com/terrablue/gpbot/blob/master/routes/index.js#L25-L27
- blueI do believe that htia function can be replaced by https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Uint8Array/fromHex today
- nevetUint8Array.fromHex() - JavaScript | MDN
- bluewhich is so nice!
- bluedreamreal: java equivalent: byte[] bytes = HexFormat.of().parseHex("CAFED00D");
- blue(need `import java.util.HexFormat`)
- * nevet joined #primate
- * blue!~blue@user/blue changed the topic to: https://primate.run | this channel is mirrored to the Primate discord, channel #irc
- phalethnot too sure I ran the right command https://images4.imagebam.com/de/91/9f/ME1AZ705_o.png
- bot<discord:blue> Looks good
- bot<discord:blue> But you can also drop the mvnw nonsense and use maven directly
- phalethmaven: not found
- bot<discord:josephbottinger> mvn and mvnw
- phalethmvn: not found
- bluephaleth: https://gitea.repopack.app/jottinger/bytecode.news/commit/3162d8ed1ae5d7d789b7005468e144bc44f3cb87
- bluedreamreal: fyi https://github.com/terrablue/bytecode.news/commit/3162d8ed1ae5d7d789b7005468e144bc44f3cb87
- bluephaleth: I'll move that jottinger org to `blue`, on gitea, if you don't mind
- blueit would be nice if you could include this primate app in your deployment, and it would be able to reach the nevet backend
- blueso three nspawn machines: pgsl, nevet, and primate
- bluethe only one that needs exposure to the world is the primate one
- blueis this possible?
- blueregarding mvn, you need an image that contains mave
- bluemaven*
- bluephaleth: https://dpaste.com/GWFBVPGA3
- phalethyeah, trying to make it work with the zip first
- blue`maven:3.9.12-eclipse-temurin-25`
- phalethdpaste.com blocks my proxy, but don't worry, it builds
- bluedreamreal: the most relevant part of that integration is the otp/request route: https://github.com/terrablue/bytecode.news/blob/master/apps/primate/routes/otp/request.ts
- blueit takes JSON from the frontend, verifies it's an email, then sends it to nevet
- bluemost of this is boilerplating that will later be replaced by the opencpi client
- blueso: client.verifyOtp({ email })
- blueshould replace https://github.com/terrablue/bytecode.news/blob/master/apps/primate/routes/otp/request.ts#L15-L23
- blue... and this probably shouldn't be a GET route
- blueanyway, I just need something for phaleth to work with. once we have that threeway setup, I can get productive with it!
- blueexpect... greatness!
- phalethturns out nevet runs on postgres 18.3 https://upaste.de/raw/5gH
- bluevery nice
- phalethyeah, it keeps crashing
- bluelol
- bluephaleth: https://gitea.repopack.app/blue/bytecode.news/
- phalethactually, the connection failed, so I
- phalethI'll try postgres 17.9 tomorrow
- blueok
- phalethgotta go now
- blueciao
- phalethbye
- * nevet joined #primate
- * blue!~blue@user/blue changed the topic to: https://primate.run | this channel is mirrored to the Primate discord, channel #irc
- * nevet joined #primate
- * blue!~blue@user/blue changed the topic to: https://primate.run | this channel is mirrored to the Primate discord, channel #irc
- * blue joined #primate
- bluedreamreal: https://github.com/primate-run/primate/issues/251
- nevetProposal: Add `AppFacade#env(key: string)` · Issue #251 · primate-run/primate
- bluechovy: I believe automatic env loading is also something you have expressed interest in in the past
- bluejreicher: if you feel like commenting this, you're welcome! https://github.com/primate-run/primate/issues/251
- nevetProposal: Add `AppFacade#env(key: string)` · Issue #251 · primate-run/primate
