Q: What part of a forge do you work on?
A: I created go-fed and its associated libraries to tackle ActivityPub federation in the go programming language which tends to be popular for forge codes as well as other server software. Gitea is based in go, for example. And go-fed addresses the problem of how to federate, from one piece of software to another, and also aims to abstract out that (as much as possible) from core app functionality. So it has a little more implications beyond just federated forges. It could be federating other software. I do want to caveat that with vocabulary in that go-fed does a little bit of code generation around vocabularies and one of the vocabularies that was included was a forge related vocabulary put up by the forgefed folks because it was at a sufficiently concrete level of detail that I could actually use it. It's one of the first domain specific schema beyond just general communications related ones that go-fed comes and pre-ships with. That's been my main area of focus.
Q: What motivated you to work on that specifically?
A: In 2017 I had a lot of free time on my hands and I figured I wanted to exercise a bit of my Open Source related skills (at that point it was non-skills, I had no Open Source activities). So I wanted to find a protocol I could pitch in with and ActivityPub was just finalized and I thought this seems like it could be a cool protocol to implement. Not realizing ... here I am several years later, still with some tasks on my plate to do. I think my motivation has transformed from one of personal diversion to one of ... I think it grew into personal interest beyond my original diversion.
Q: At some point you realized that you were more interested in applying ActivityPub to forges rather than something else? How did that happen?
A: Once I got finished with the core go-fed library, it was very clear that it was very complex to use because ActivityPub is very hard to abstract out. So there was two ways that I could take it. I could either start trying to graft it into existing projects as proof of concepts or let other people pick it up from there and really flush it out. Or I could try to make a more core bells and whistles kind of base server framework. And I want to pursue both, unfortunately I don't have the personal energy and capacity for both. So with the encouragement of the community such as Arnold from SocialHub, he encouraged me to post my experience to GitHub where that big issue is. That's the product of many conversations between myself and casual conversations with others; say with Drew DeVault who is in charge of his own forge software and who is making a living off of that or other people from forgefed. I tried to take all of that and package it into one big "here is a vision", it's not "the vision" but it's at least a starting conversation piece.
Q: From an outsider perspective it looks like go-fed or an ActivityPub library that implements whatever an application needs to have this communication feature is like any other library. And that it might be useful to forgefed as a way to show it actually works, to Gitea... Yet, as you mention, years later, this library is not widely used. Why is that?
A: We don't have to beat around the bush: it was not adopted by too many people at all. And the core reason, it turns out, is not implementing ActivityPub. Yes, the specs has some gray areas and some, let say "holes", where it's like "oh, what am I actually supposed to do here?". It's very generalized and open and broad. Which meant when I went in with my very conservative mindset of "I just want to implement the protocol", it included all these gaping holes and when you step back and look at it and what people want... In my experience it's not what they want solved. When they think federation, they think "I want to be able to communicate with (pick a software) in (pick a domain & language)" and that required much more detailed concrete resolutions like "what exact messages are you sending / receiving over ActivityPub ?", "What does it mean when a certain field is populated in the data or not populated or populated multiple times?". And sometimes these multiple times are different objects. So you have all these different specific considerations when you go and federate and go-fed does not solve any of that. And that's the core problem people want solved, right?
Q: It's not just go-fed, it seems like it is all the libraries that suffer from what you just described. Even the python language does not have a library that is ready to use. Or even if you take Mastodon, it's not really easy to extract the part that handles ActivityPub. It looks like your describing a generalized problem.
A: I view it a little different. I would say it is a specific problem but it is universally shared. So the people wanting to build a forge have this problem with the forge language. The people wanting to build economic related things have the same problem but in an economic domain space.
Q: You derive no income from this activity?
A: Correct. I've put a little bit of my own money into the OpenSourceCollective just as a thank you tip jar that I can use to thank people who have contributed to go-fed.
Q: I will now start with a series of questions about Gitea itself, to understand how go-fed would fit. The idea is to link what you remember with what vocabulary Gitea needs for federation.
A: It's been a while since I looked into the specific details so I apologize if it's a bit fuzzy.
Q: It's perfectly fine if you say: "Hum, I'm not sure". Gitea has a DVCS, it's git, so you would answer "yes". What about merge or pull requests?
A: Yes, it has that concept.
Q: Issues?
A: For sure that's been a major contentious point. I'm very "pro" and others are very "con".
Q: It's implemented in Gitea and there are Actors or Activities that go-fed would deal with. CI?
A: I did not think of this one.
Q: Continuous Deployment, Operations?
A: Same answer. Do you expect my answer to be about "can go-fed help in this area"? Or is this worth pursuing?
Q: The yes/no is about you thinking, in the context of Gitea + go-fed, is it in scope or not.
A: It's tough.
Q: Yes, I realize that, for instance, Continuous Integration is like "hum?". In forgefed I've not seen Continuous Integration. It seems to be far away. Yet, some people say that "Yes, Continuous Integration is part of what makes a software" and if you remove that you remove something essential. So it has to be conveyed: there are events, it's an actor that does things. That's why I ask the question.
A: Yeah, and go-fed, like I said before, does not technically solve these nuances. It can help be a part of the story. That's why I'm saying "yes or no" is very hard. As it stands today, with the code checked in, it does not have a concept of that.
Q: You're not forced to say "yes/no" you can say whatever you want. Wiki?
A: As it is today go-fed does not handle wiki semantics but I don't think ActivityPub as a whole is prepared for wiki like documentation. So it could be a more fundamental ... there is a much deeper modeling kind of problem there.
Q: Webhooks?
A: I think they are very different problems. But that's my perception, maybe I'm mistaken. Webhooks is more like modding like people doing cool things when certain events happen. Whether or not that needs to be ActivityPub related I think is a good question. If it is, go-fed does not have anything currently checked in that's like "this is a webhook type of vocabulary definition or interaction". Again, going back, the general problem is how do you define those interactions. But go-fed could at least provide the transport layer basis to facilitate that if that's needed. But if it's more "my server happens to federate other things but the webhooks all stay local on my machine" then go-fed is not really questionable.
Q: Integrations (mattermost, redmine, jenkins...)?
A: There could be a future where there's multiple forges and for some reason... For instance my building has a bunch of hackers living in here and we have a dev server and a prod server running the same software in the cloud but integrated with more tools. We all hack on our own servers. And they federate with each other: same code and we just sync them using a git push from our dev federated servers to the prod one. Again the software on the servers isn't changing, just the code they are hosting is. And every time that guy gets a push on the federated one somewhere, it says "Oh, time to trigger all the integrations, run all the webhooks, get the feedback, maybe do some custom workflows". ActivityPub could help facilitate the notification system say, for example, between integrations on a case by case basis depending on what you want to accomplish with this sorts of integration. go-fed in this case is again just facilitating the transport and allowing you to translate schema into actual code. What the schema are and what those facilitated interactions are... it's a kind of "the world is your oyster" situation".
Q: Snippets?
A: This gets interesting because I come from a go language background. And the community of go has a snippets paradigm where you embed a snippet of code in a web browser page that you are browsing, typically you can also hit a button there that says "execute" and you can run that little bit of go code and see its output. That's really handy because that server is running a mini go environment to take the code, build it, compile it in a sandbox and then execute it and stream the output back. When you tell me "snippets" I come in very biased with that. But if it was an ActivityPub kind of situation, then you get some more complex web page interactions with code snippets and facilitating developers productivity. Where you could write some code snippet inline into paragraphs and get some real time feedback.
Q: Pages? That create static web sites from a repository.
A: ActivityPub and static web sites are a tricky beast. Fundamentally I don't think go-fed would help at all.
Q: Package registries? PyPI, Debian Packages, etc.
A: I haven't thought of that.
Q: API?
A: This gets tricky. ActivityPub, fundamentally, is kind of an API. It tries to be all in one. If you want to take, say, the mastodon route where you use ActivityPub for specific objectives you can have a customized API for others. For example the UI has its own API. go-fed is not going to help with any of this custom bits. Like if you want to have a RESTfull API or GraphQL. Even on that topic there is some contention in the community: can you represent ActivityPub in GraphQL? I've seen some thoughts around that and my thinking is "yes, but in a very limited world". You'd have to scope ActivityPub really far down. (sigh)... don't know.
Q: What you're expressing is that there are multiple APIs and ActivityPub is one of them.
A: It becomes more of a question of capability than the actual API format. So I think that what REST, the philosophy of REST has really done, is turn all capabilities into its API. If you want to add a book, there is an endpoint for that. If you want to move a book, there is a different endpoint for that. However ActivityPub says there is one endpoint and the data you send conveys "add book", "remove book", things like that. It changes the endpoint paradigm over to a data paradigm. Therefore, I think, one of the hindrances to ActivityPub adoption has been this inversion of mental model. Because so many existing tools and even other efforts such as OpenAPI that generates beautiful code API for you, use these endpoints as actions concepts. Whereas ActivityPub uses data as actions concepts.
Q: Since you worked so much with go-fed and Gitea, thinking about it, could you tell me how you envision go-fed and Gitea working together? How would import / export work in that context?
A: So I want to be very clear about that: I did not graft go-fed into Gitea on a technical level... yet. When you say import / export you mean what Gitea could share with the outside world and therefore receive back. The biggest draw for me (which is highly contentious within the community) is the ability to democratize the socialization around software. So today if I want to make a bug report to a given project, I have to go their Gitea instance and register and open an issue. If I want to open a mastodon bug, I have to go to GitHub and have an account there and open an issue. Similarly for go-fed, it's also on GitHub. However a fundamental game changer could be: you have your account on your self-hosted forge and you're able to comment on an issue on software across those silos boundaries. This is specially useful in the Open Source model where there are forks and people like to take forks and pick them up and host them on different servers and services. You lose the sense of community and that's why I think a lot of Open Source friction comes from. You get these personal interest conflicts which can be in various forms. Sometimes they are very gentle and friendly divergences, sometime they are not. And that opens the door to moderation which is always going to be a  question. But at least having the opportunity to carry over nicely the community and keep track of these multiple forks contributions, anything to facilitate the human need around the software. There is a criticism I've heard a lot around trying to apply ActivityPub to forges: git is already decentralized, just send email patches, email is federated: done, we have federation. And they would also claim: email is also a social environment where you can just send emails and done. Take your email community elsewhere. Mailing lists have organizations around them and are still there, similarly to ActivityPub as a communication layer. But email is relatively unstructured. Trying to add new strange headers has its own considerations. And using it as the basis of an interchange format for two servers sharing communities and self hosting code, I think, is a lot more difficult than, say, going with an ActivityPub based approach which is a bit more structured on its fundamental data operating unit. Therefore you can do a lot more, reason about the problem space a lot more easily.
Q: If we take one specific point you thought about to apply go-fed to Gitea (for instance an issue), did you try to imagine how it would go?
A: My thought process when trying to solve an interaction problem (that's the ultimate goal) is to find the behavior you want to see. If you want to see an issue as open, the creation of an issue, I try to take a step back and identify what are the players involved in this interaction. What is the outcome and actions wrapping this data outcome. So ActivityPub really has like a data payload and an action, "note" being the canonical mastodon one. And the mastodon canonical actors are user A and B. There are some ideas around having the actual machine servers themselves being actors. There are also thoughts around having a repository be an actor. To receive these "create" issues. This can help dictate a lot of foundational philosophy (I don't know how to describe it), a way of thinking and reason about a problem. What gets tricky is then, when you go beyond the first interaction and you take the second one: I want to add a tag to an issue. I want to close an issue. You start to get a series of issues and when you take each one individually, you might come up with an identified data payload, action, vocabulary and actors that make sense. But when you take a step back and look at your huge list, you notice ... maybe these actors are not all aligned. Maybe it's not always a repository, maybe it's a repository AND issue. And then you have the question of "OK, how many actors do I really want to be creating?" Is everything going to become an actor? I doubt that's really scalable. The engineering comes in and you have to create artificial limits on yourself to come to a design that is perhaps less theoretically pure but perhaps easier to reason about, find some rules. This is my way of thinking, trying to tease out this problem space. Other people approach it differently.
Q: If I rephrase: you struggle between something that is abstract ActivityPub related where you have something very generic and the practical application that requires doing actual code and something understandable. So you have to compromise and maybe sacrifice some of the theory?
A: If I could give a concrete example, let's take mastodon 'create note'. They have an actor on one instance and an actor on another instance. One creates a note wraps it, ships it to the other user and it's done. Someone had to sit there and think about: "OK, if I want to send a message to another human and that is my goal, what does this interaction look like?". And they could have thought: "well I want these two actors to be humans and I want them to send an article wrapped in a 'create'". But an article must be long, it's like a web page, let's not use articles, let's use note. You get into these very vocab specific questions and then people also ask: "and what if the note has an image embedded in it?" Do I need to send a 'create image'? Along with the 'create note'? Do I need to put them into a collection and order them in some way so now it's an ordered collection? And so you have all these different people and all these different perspectives on how to do the actual fundamental modelling of an interaction when all you want to do is just ... you know ... five seconds and a pigeon later you can get the message.
Q: It looks like there is a basic transport layer where you send a message, you receive a message there is a payload. Everybody agrees on that. And then there is a very difficult granularity or high level understanding of what the message actually contains. Which can vary from "I don't know anything about the message" to "I understand every detail", that's what you're saying about an article, an image. Do I care about what the page contains? Or do I consider the pages a bunch of bytes and that's it. How would you put the cursor between what you define and what you declare to not be your problem?
A: From go-fed's perspective it provides all the tools to start playing with this. So if you wanted to test wrapping an article with a 'create' or an 'ordered collection' with a huge payload inside (I don't recommend actually doing this, it's just an example). It allows you to have this transport send/receive but does not tell you what you should send or what you should receive. And it does not tell you which actor is doing the sending and which one is doing the receiving nor does it tell you how to map those actors to your applications concept. All this ambiguity is very overwhelming in two senses: a) you have to get very specific to really understand "if I get a message from mastodon that says 'create note', is it going to be a short text note maybe with a hyperlink and maybe some images attached to it?". So coming to this agreement takes a long time. It's a lot of talking with people you can also say "my software is just going to do it this way, take it or leave it". Unfortunately that's the nature of a federated environment. That kind of freedom, on the flip side, means... let say a forge software gets built and you've already solved all these specific concerns and let say that economic people have done that and solved all their specific concerns. A third developer can come along and say "they already solved that specific concerns for forges and that specific concern for economics, my application is now going to understand both of them" and suddenly you can now have a platform that says: "hey, you contributed? let me notify the economic network and give you some economic benefits".
Q: If you were to implement go-fed in Gitea, what would be your first baby step?
A: It would be to demonstrate some sort of federated behavior. Hopefully a simple interaction. And the simplest one I can think of are like 'open an issue', 'close an issue'. Which unfortunately is not the core of pulling code or code review but just to get to the point to be able to have your actors defined in your software and being able to send and receive messages and process them in an ActivityPub way with the intended side effect that you want to have. There is is a lot that goes to the federated step.
Q: Something comes up frequently when discussing about moving things around between forges: the references. References to a user in an issue, to a pull request in a git commit, etc.
A: From a UI/UX perspective, there is absolutely a wealth field of "how do you represent these sorts of cross federated servers interactions". Do you show them the same way just with a highlighting and a note saying "this is federated"? Do you give them a totally different treatment? Mastodon gives a federated timeline a very different treatment than the local: you have to go and seek it, in its own panel (I'm still using the old UI). In terms of user expectations, I think, in this generation of internet servers and software, I think a lot of the old late 90' early 2000 federated UX patterns are long gone. It's both a blessing and a curse because you loose that generation of people that grew up understanding what federated meant and what to expect in these kind of UIs. The blessing is that you don't get the UX of the late 90', you're free to pick a new paradigm if you want. I think taking a first stab at it (and you don't even need federation working, you can mock it and fake some data as you wish and present that). I think both are worth doing, for different reasons. The UX one is way less understood, way way less.
Q: Did you ever think about GDPR and federation?
A: That's a tricky one. It's a blessing given the current architecture of the internet, from my personal view. I think the European commission and some European bodies are starting to learn about federation and that sort of alternative ecosystem. Encryption is going to play a key role in enforcing some of these ideas because what winds up happening in a federated system is data locality and these sorts of artificial data borders become more fuzzy. If you compare the internet of 2021 to 2001, nation states are much more prone to applying laws to the internet based on geographical borders today than 20 years ago. Christopher Weber is working on the philosophical actor model and ActivityPub and working on basically the next evolution that has a lot more security guarantees than the ActivityPub of today. The ActivityPub of today is a gigantic security mess, unfortunately. I would give it a thumbs down in the context of GDPR.
Q: What about your roadmap?
A: Every year I try to set myself some goals. I don't quite hit them every time, unfortunately. This year my goal was (and due to COVID it looks like it's not going to be hit again) to get apcore to a version one. Unfortunately this year I haven't gone to work on that at all. That's the bad news. The good news is that in the meantime several people have actually picked up on it and started to actually using it and actually making progress, federating and interacting in brand new applications. They are sending PRs and wanting to sit down and talk and understand and get more features in. That's really nice to see. On the other half, I've been wanting to support any sort of integration that might use go-fed. For example if someone chooses to use go-fed and Gitea, would you be able to make this change and that change? I'm generally open and receptive. I may push back because from a philosophical standpoint go-fed is very conservative and really meant to tackle the "get things from point A to point B" and in a way that your application can easily understand. I don't want to inject too much specific, either forge or mastodon ... into it. What that may look like in practice is, one of the guys who worked on the apcore side needed additional schema, more vocabulary to send and receive. So he reached out and said: "are you opposed to including this vocabulary in go-fed?" and generally when it comes to more vocab I'm cool with it. All that's really doing is giving you the ability to use the vocabulary but it's not the library telling you what to do or how to do it. In terms of actually doing the Gitea integration of go-fed, I had to set my own boundaries. 
Q: If you had a magic wand, what would you wish for?
A: I would like it such that one day I could push some code up and mark that commit as tagged for release. And hop on over to social media and be able to give my mom a call and say "Hey, mom, look what I did here, you can share it with the rest of the family". And she might not understand it, she like to be involved though and so she would be like: "Oh, look at my boy, he's doing coding!". And this notification would come from a forge. I could be doing my own very technical thing and she could be on the more social server but they still talk via ActivityPub.
Q: When it comes to forges and federation, is there something you think is working in the context of working with multiple forges?
A: Are you including the current tools that are out there?
Q: Yes.
A: I'm a very plain person, not using many bells and whistles. My personal value is one of staying self organized so I really value anything that helps me stay more accountable and organized. Whether that's tags on issues, or lists and milestones listing all these issues and being able to plan once / organize once and have it be disseminated out for others to be able to analyze, consume or ingest in whatever UI/UX is best suited for them. I think GitHub does it well if only because it is rigorously standardized. I think an ActivityPub forge could do it really well because different forges could have different UIs to the same organization data. They would have different burn down charts if they were doing agile, more kanban or grassroots: everyone can have their own view of that.