Augustus Mayo
Appearances
Oxide and Friends
RFDs: The Backbone of Oxide
Yeah, that does actually talk to GitHub directly at the moment. Oh, wow. Yep. Hopefully not for long. Our goal was to model it in the front end, see how people liked it. And then once we have a good idea, then we port it back down to the back end.
Oxide and Friends
RFDs: The Backbone of Oxide
One of the complicated bits, though, is we have this back end processing bit so that we don't have to go to GitHub to pull data, like all the static content from the RFDs and the images and all that. The problem, though, is that database we want to talk about sort of revisions of RFDs. And this is something we did recently. But we currently only expose the currently latest version of RFD.
Oxide and Friends
RFDs: The Backbone of Oxide
But we have a database of every commit processed. So eventually, you could go back in time on the RFD site. And then the idea is, how do you tie comments into revisions? And what's that mean? Comments on a specific revision, how do you then pull them all together? So in the process, but yeah, as Chris was saying, we're building GitHub.
Oxide and Friends
RFDs: The Backbone of Oxide
That is absolutely correct. So if you don't know, when you have a private repo and you add an outside collaborator, you start paying for it. So you start racking up pretty big GitHub bills around that, as well as it's just a hard list to maintain and understanding who still wants to be on that list. Yeah. And also, it meant that we have to give full access to every RFD to everybody.
Oxide and Friends
RFDs: The Backbone of Oxide
We don't have any way to curate that. And we had some workarounds in place, but we have some static config files that list a handful of RFDs and this subset of people get them. We had no real good permissioning system around it. And that was one of the main reasons to rewrite that database and back-end processing was... we needed to model RFD access around actual permission sets.
Oxide and Friends
RFDs: The Backbone of Oxide
So being able to grant things all the way down to you have access to a specific RFD, or maybe even have access to a specific RFD and the discussion for that RFD within the RFD site itself.
Oxide and Friends
RFDs: The Backbone of Oxide
So we had this weird... I'd have to look at the actual date. We had a weird workaround prior to the permissions where you could technically mark things as public that we did for one or two. But it wasn't until we actually launched the new RFD API, which was, I don't know, sometime this past year, to actually flag them.
Oxide and Friends
RFDs: The Backbone of Oxide
Yeah, that's a good thing to point out. There's a difference between public, as in you could sign in and see stuff, versus now you can actually just go to the URL and you can actually just search the things that are public, as in they're actually public, not this fake behind a log in public.
Oxide and Friends
RFDs: The Backbone of Oxide
Yeah, so I know it was less than a year because it was at last time when we all met up at the office. That's when I demoed the barely working API that was just tied together with string.
Oxide and Friends
RFDs: The Backbone of Oxide
And honestly, so all of this permissions and group stuff is, so the RFD site was the first test of this, but that's actually now, that's been factored out of the RFD site, out of the RFD API, and now sort of powers a lot of our internal application permissions. And now the RFD API gets updates now from the stuff we're doing throughout the rest of the company.
Oxide and Friends
RFDs: The Backbone of Oxide
No, go ahead. I would say part of our goal with the RFD API was planned from the beginning to be open source. So part of it was also just sort of detangling from anything that was like oxide specific and trying to make it a more abstract system. The RFD site, I'll let Ben speak to that one, was I think more of a challenge.
Oxide and Friends
RFDs: The Backbone of Oxide
Yeah, in terms of the API, it's probably a decent place to start. It's also built on top of other Oxide stuff, like Dropshot and Progenitor. So there's a built-in CLI that you get out of it for free. which is really nice. But really, you just need a guess.
Oxide and Friends
RFDs: The Backbone of Oxide
Yeah, so any shame, right? The end user doesn't see any of that, though. Oh, totally. Perfect technology. Internal shame.
Oxide and Friends
RFDs: The Backbone of Oxide
The only real assumption, it makes a couple assumptions maybe around, if you read RFD1, actually, is what a lot of this is modeled on top of. So it does make some assumptions about how we run RFDs, like what the states are, what they mean. But in theory, you can point this at a repo. I've been working on trying to getting a setup guide to be a little bit cleaner.
Oxide and Friends
RFDs: The Backbone of Oxide
Benji ran this himself and sent me a whole bunch of really helpful notes on how painful it was. So there is some work to be done there. But it did make some assumptions around your using ASCII doctor, some of our use cases around mermaid diagrams that require some installation. Realistically, it should be pretty straightforward to run. And what you get out is essentially a nice database.
Oxide and Friends
RFDs: The Backbone of Oxide
Technically, it runs on Postgres. So you have a nice Postgres database of all of your RFD contents that you can then really do whatever you want with. We happen to render them as an RFD site then.
Oxide and Friends
RFDs: The Backbone of Oxide
It's fairly coupled to that right now. Essentially, we have these... If I go into a little bit, so the processor works on this concept of jobs where we scan a repo or we accept webhooks from GitHub to generate jobs that are going to then look at a specific commit and look within that directory structure. So it's less coupled to the branching model and more coupled to the
Oxide and Friends
RFDs: The Backbone of Oxide
struct the document structure so we have a director that has rfds then you have a rfd number and then a rfd document uh outside of that you could write a separate scanner that you know looks at branches and does make some other determination to create a new job that says okay here's where my rfd is located i need you to go do some processing on it which and that processing then
Oxide and Friends
RFDs: The Backbone of Oxide
pulls that content down into the database. It'll do things like generating PRs if you need them. Like when a RFD goes into discussion, we generate a PR on the GitHub repo for people to start discussing it. Things like closing them out or updating things like idle states.
Oxide and Friends
RFDs: The Backbone of Oxide
Yeah, I think, and especially from the machine side of it, it makes a lot of sense. And Benji mentioned this earlier of part of our goal is then how do we, as engineers, I think it's fairly comfortable. We use GitHub all the time. But how do we then bring that to everybody and make everybody comfortable with it? And I don't think the plan is to like
Oxide and Friends
RFDs: The Backbone of Oxide
force everyone to, yeah, you have to learn GitHub and be super comfortable with it. So understanding what's it look like for the RFD API to make a new RFD for you if you just give it a title or when you want to edit content.