I don’t understand. Why would ForgeFed not allow repo teams members to be decentralized? That would be very limiting if all project team members need to be on the same server.
Oh, sorry, I probably phrased it poorly. Project team members can be on different servers.
Also I don’t understand the .git reference. Git doesn’t have a location, it’s decentralized by nature. You clone it and you have a copy. You fork it and you have a copy with your own url. I would expect fork to work similarly in ForgeFed. If I fork https://alice/repo to https://jaywink/repo then I have a fork pointing to my server.
When something has a clone URL, then that’s the location. What I mean is that a project consists of many sub objects: The issues, patches, MRs, wiki pages, git (or other VCS) repos and so on. And even those have their own sub objects: Each git repo is many files in a
.git/ dir. Each issue has its collection of replies, dependencies and so on. We have an assumption, that when you host a git repo, you host all the files in the repo together. Sure, people can clone your repo, but your copy that is in your authority has the
.git folder on your server’s filesystem. We aren’t trying to decentralize it, allow each git commit/tag/branch to be on the server of the person who created it. So what I’m saying is, the choice of how deep we want to go with allowing the small sub objects of a project to be split across servers is a somewhat arbitrary/flexible choice. Conceptually, you could think of an issue as a git repo with 1 text file, and then supposedly now “issues don’t have a location and are decentralized by nature”, right?
I just wanted to ask the question: If a specific repo with a specific URL/owner and all its commits/branches/tags are together on the same server and that’s okay, why wouldn’t it be okay if a repo and its issues are on the same server? Why are these two cases different?
You’re free to open an issue, but repo team should be able to enforce access control and CoC rules.
They can. They can close the issue, edit it or even delete it - just like in centralized forges.
If they’re lucky and author’s server cooperates with them and applies the edits anyway, this point is covered, moving on.
Think about issues in general, not specifically in forges: an issue list is like a to-do list of your work plan. And you want the confidence things don’t change, get edited out, etc. without you feeling in control over things.
This is just one use case and it’s not even the GitHub one. This use case shouldn’t rule the whole spec.
Technically, a list of issues is a to-do list of stuff to do. Bugs to fix. Features to add. The issue part of ForgeFed is about task/issue/project management in general. I often use issues to manage and track work on a public project at a public spot, and I’m sure I’m not the only one. This use case shouldn’t rule the spec though, I agree, we just need to be sure the use case is supported and possible.
Hmm I’m not sure :-/ when people HTTP GET the issue, they’d see the edit the author made, that repo team isn’t even aware of. Is that a desired situation? Imagine author changes “critical issue, be careful” into “issue solved, it’s safe to install now” and people believe that lie for a whole week because repo team didn’t get notified on the malicious/accidental edit.
I think this “attack vector” is being given too much space in this discussion. Also this is simply how the federated web works. If an object owner changes their object, it might be different than cached copies on the other servers. You can’t decentralize and centralize at the same time - you have to choose one.
The Fediverse doesn’t have that use case right now, as far as I can see. So it can’t be how it works. A toot’s purpose is to reflect the author’s thoughts, so toot editing would just mean it’s a more accurate up to date reflection. And if someone relies on an outdated cache, the worst scenario is that they see something you said in the past and haven’t seen the new version yet. It’s like watching yesterday’s news, not being aware yet that there’s some more stuff. With issues, an edit by author may sometimes not be desirable at all, from repo team’s point of view.
I’m starting to believe
aaronpk were right in the SocialCG room suggesting that both are valid cases. Didn’t even think of that, I’m glad they brought it up.
Me too. Actually, I’d like to make a new proposal: Let’s support both.
Create flow I’m suggesting is closer to the traditional fediverse way of distributing content and the
Offer flow is something that will suit better workflows like your todo list example.
Create flow is how purpose-is-expression-of-author-thoughts is distributed. But there’s something fundamentally different about objects that may get a long long lifetime of edits and updates outside of the control of the original author. However, if we remove the assumption that repo team is accountable for all the content and updates etc., I agree! I have some technical points though, I’ll write those at the bottom of the post.
As there is no concensus in the working group to which one should be the one and both clearly have advantages and problems and neither solves all use cases, ForgeFed should document both. Server implementers are then free to choose which one applies to them, depending on whether they are building a replacement for GitHub or a project todo list which requires centralizing the issues under the one server and acceptance of all created issues.
Even if you build a forge like Gitea/GitLab/githu8, you may wish to support hosting issues on repo team side.
Let’s support both. Do we agree on that @jaywink? Both flows supported and documented in the spec, and all assumptions in the spec take both approaches into account, making sure they’re both possible.
Technical points to resolve
@jaywink, if we agree on supporting both flows, there are some little technical questions I’d like to answer.
Be patient with me for just a bit more, I hope we’re almost done with this huge thread ^ _ ^
On the Fediverse, if you reply on my toot, then my toot now lists the ID URL of your toot under its
replies. Am I right? There’s no need to
Offer anything; you merely
Note and that’s enough for my server to know that it can list your toot as a reply to mine, so that people reading my toot can see your reply, and all the other replies of course. Am I correct so far?
Now let’s look at the
Create flow for issues. If I understand your proposal correctly, it works the same, right? You
Create an issue, and the repo then lists its ID URL under its list of issues, right? There would be some property for that, say
issues or whatever, much like
replies is used for listing replies on a toot. Am I correct so far?
Now let’s look at the
Offer approach for a moment. Imagine I want to
Create an issue, then do some edits and tweaks, and then finally I want to
Offer it to the repo, and let them make a copy and take it from there. In other words, before I
Offer an issue, it’s possible I separately
Created it earlier. Correct?
Now we have a little problem: When you
Create an issue, it automatically implies to the repo that they should list your issue. Maybe I don’t want that, maybe I want to make some edits and later I will
Offer them the issue and not have to host it or worry about it ever again. This problem doesn’t exist on the Fediverse as far as I know, because once you publish a toot, it’s clear that it’s desired and safe to list it under the toot on which it replies (if there’s such a toot). When you
Create a toot, you basically report its existence to the world. But here, since we have 2 flows, it’s not clear whether
Createing an issue means you’re reporting a bug to the repo, or you’re just publishing some piece of text that you’ll want to edit and send it later.
What do we do?
IDEA: When you
Create an issue, even if you later want to edit it and
Offer it, it’s okay if the repo already lists your issue under the repo’s list of issues. There’s no harm in that. Later, when you
Offer the issue, repo can say “oh we already list your issue but now you want us to host it” and repo makes a copy and lists the copy instead of the original issue you’ve been hosting (but their copy may still link to your issue, so author authenticity proof is preserved etc.).
Now there’s another little question. Someone
Created an issue, but repo isn’t listing it for some reason. Maybe delivery failed. Maybe issue was accidentally treated as spam and ignored. Or idk, any reason. But people see the
Create activity and they’d like to make sure the repo knows about this issue and lists it. Perhaps it would be useful to allow an issue to be reported even after its creation, e.g. using an
According to AS2 vocab spec,
Announce can have a
target which is the entity to whose attention you’d like to bring the
object. So an
target being the repo (or even without
target, I suppose, simply detecting that the
object is an issue on the repo) would be treated as a way to report an issue, and the repo would list the issue on its list.
Supporting that also means you can
Create an issue privately, discuss and write it gradually, maybe even collaboratively with other people etc., and then make it public and
Announce it when you want to.
Another point: When you
Note as a reply to another toot, and that toot lists yours as a reply, you don’t get an
Accept. I guess there’s no need for that? I guess in your client UI you’re redirected back to the toot on which you replied, and you can see your reply there. So, with issues, when you
Create an issue and the repo lists it, is there a need to send an
Accept to let you know your issue got listed?
Unlike with toots and replies, for issues perhaps some person/project would like to manually review issues before listing them, and also if you post some critical bug you’d want to be confident that it’s listed and everyone can see it. There’s no harm in sending an
Accept. I think it would be nice and useful. But in the spec, should we require that an Accept it sent once the issue is listed?
PROPOSAL: Let’s say in the spec that the repo’s server SHOULD send the Accept, since that’s also the statement for
Accept on a
Follow in the AP spec:
The side effect of receiving this in an inbox is that the server SHOULD generate either an
Reject activity with the Follow as the
object and deliver it to the
actor of the Follow. The
Reject MAY be generated automatically, or MAY be the result of user input
So we’d say the repo’s side SHOULD send an
Accept if it lists the issue, and SHOULD send a
Reject if it sees the issue but decides not to list it. We could also add those parts about manual review and “MAY” stuff about not sending a Reject to protect privacy and so on.
Hmm there’s also the question how the issue author would know which issue edits/updates to apply and which to reject. They’d get some
Update with an OCAP attached, and would need to figure out whether the OCAP gives the
actor of the
Update permission to perform it.
PROPOSAL: We don’t have any OCAP stuff in the spec and we’ve haven’t made any decisions on OCAP usage. Even if it turns out to be complicated for author to use OCAPs, we could decide to rely on repo actor sending an
Accept or an
Announce on approved edits, and that would make it very easy for the issue author to know which edits to trust. The repo actor would essentially do the OCAP verification for the issue author, and just “give them green light” to apply the edit. So I’m proposing to leave this question not finally decided. To have this proposal documented, but finalize the decision only after more research into OCAPs (for example, if OCAPs are publicly verifiable and the role/permission system has a clear spec, then there’s no need for those Accept/Announce tricks).
And one last point. I propose the following rule: When you
Offer an issue, that means you want the repo to host it. If they
Accept it, that means they host a copy, and the
result of the
Accept is the ID URL of that newly created copy. When you
Create an issue, that means you’re okay with hosting it, maybe you even want to host it. The repo’s server gets to choose whether it lists the ID URL of your issue, or makes a whole copy. We will recommend that by default the repo’s server should just list your issue and let you host it, but it’s also possible it instead makes a copy, there’s no guarantee. We could explain in the spec in which cases it would be desirable to make a copy automatically, and suggest that people don’t implement stuff like that unless there’s a real reason (e.g. to closely protect some critical security issue, or manage a to-do list, etc.), and remind them that they can always make a copy manually/later if something isn’t right.
So, when you
Offer an issue and the repo wants to list it, it MUST make a copy. When you
Create an issue and the repo wants it, it SHOULD just like the ID URL and let you host the issue, but it MAY decide to make a copy. Then comes text about recommending not to copy and explaining/giving examples in which cases the copy would probably be the desirable option.
Hmm but maybe “repo MUST make a copy” is too harsh? Perhaps just SHOULD make a copy? What does it mean, if you
Offer an issue but repo lists the ID URL instead of making its own copy? Perhaps we should allow repo servers to never host their issues? That way simple repo-only servers don’t have to handle issue stuff, they always want the issue author to host it. So, upon
Offer, repo SHOULD host a copy, and upon
Create, repo should just list the ID URL, but neither is guaranteed. However, if repo sends an
Accept, it MUST do one of those two things, and which one happened can be detected: If the
Accept has a
result field, then a copy was created; if not, just the ID URL got listed. Sounds better?