Federated issue tracking #11
Comments
|
IMHO the only way is for the original server to do access control. What does giving a remote user contributor access to your repository mean in terms of federation? Possibly it could be as simple as federating an activity indicating that "I user Ken grant Oprah contributor rights to my repository". This has several effects:
Since Ken controls the issue, Ken's server needs to tell the other subscribers that the issue was closed. ActivityPub already has the forwarding mechanism. Other servers should maybe only accept issue closing from Ken's server, since he is the only one who really can say (as the owner of the repository) if the issue is closed. Of course if Mandy has received previously a message that Oprah is a contributor, her server could decide to accept an issue close from Oprah directly. Just some thoughts, and a vote to keep things simple and work as close as possible to ActivityPub without complexity of figuring out totally new things like ACL's. |
|
As written in another issue, an entire community exists around decentralized issue tracking. As I am more or less actively working on a such a system, I am a bit biased regarding this topic. Also, I did not (yet) have a look at how other distributed issue trackers ("dits"), like git-issues handle access control, so I can only provide what we do (or are planning to do) in git-dit: In the case of dits, issues can be freely transferred from one repository to another, so an issue does live in any repository mirroring issues anyway. If an issue is altered in some way (e.g. an assignee is set), the change is only local but can be transferred to another repo using a fetch or push. Obviously, this allows for concurrent conflicting changes. In git-dit, we solved this problem by providing a mechanism by which a maintainer can select or simply set the state which should be considered up-stream for each issue. Mere consumers of an issue simply refrain from setting this marker, or, if they have another opinion, they can override the upstream state by providing their own, locally. In the end, the access control becomes a matter of what repository you consider "upstream" and what changes are allowed by the maintainer. For large repositories with lots of issues being reported or commented, this is obviously not an option for the maintainer. For their side, we thought about having repos with global push-access, which are guarded by hooks enforcing arbitrary policies (e.g. assignees and maintainers can update the upstream state of an issue, we also provide an example). I think this choice ("leave the policy-making to the maintainers of a project") is the only sensible option both for dits as well as a federation. Anything else would mean prescribing an exact access model, and in the end, an exact workflow and thus limiting the user's freedom. As for PRs: you should have an agreed-upon upstream master. Anything else means a fork which should probably be regarded another project. In such a situation, you have one master onto which, either directly or via possibly multiple stages, patches/merge commits are applied. I would rather not want to see a specific description about who is allowed to perform such actions in a specification of the communication protocol, but rather defined messages for requesting merges which can be either granted or denied based on a maintainer-specified policy. |
|
I think it's fairly simple. The repositories don't "belong" to a server, they belong to a person or an organization. If I have permissions for a repository as an entity, then I should have the same permissions regardless of the server(s) that is on. I feel it may be more productive to consider a server as two things:
|
|
@coderkevin: That is a very interesting idea. But if that's the case, we'd run into namespace collision / reservation issue. Say a repository named "foobar/hello" has a copy on server A and a copy on server B. And another totally different person wants to create another different software in the name of "foobar/hello" on server C. Should we stop that from happening? And how? Having centralized service for name (user and organization identities) reservation would create a single point of failure. But without one, there is no sensible way to prevent name collision. Also that would be vastly different from most SCM software implementation today. I fear that could simply stop the protocol from being adopted by existing parties and thus weaken the federation itself. |
|
@jaywink: For PRs closing, I agree its much simpler, thus practical, to have downstream sending a "close" request to upstream and leave the actual closing to upstream. That way we can circumvent the whole permission altogether. @neithernut seems to have the same opinion on this, if I'm not mistaken. @neithernut: Issue syncing across platform is new to me. I'd love to hear more of it. |
|
the most important point to make is that most of the talk on this thread in describing decentralized behaviour; but the goal is federation here and not merely decentralization - a good deal more care must be taken to maintain sanity and robustness - tools that support decentralization but not true federation would need to be modified to support a non-hierarchical workflow or else they will not be useful to anyone implementing a truly federated complete solution, neither will the protocol if it is coupled to such tools
whoever ken has authorized as collaborators - ken does this by interracting directly with his home-server by adding the peer's canonical and unique user-id e.g. oprah@oprahs-homeserver.net - kens server only needs to auth oprah against oprahs-homeserver.net when she interacts with kens repo - the idea of maintaining a repo on a foreign server by interacting only with your home-server does not seem very sensible nor terribly useful - frankly its pretty goofy - in the end, every such action is a fiction until the canonical host validates and accepts them, which may not be satisfiable because they were not done atomically - it is the same reason why git commits and pushes are atomic - in a federated network, any modifications to "kens" repo that oprah makes by interacting only with her home-server can not be guaranteed to propagate to kens actual repo on kens home-server, nor that kens home-server will honor the request, or accept its historical information as truth, nor could that be done atomically as is required to maintain sanity - kens home-server keeps the state of kens repos and it must be the only keeper of the state of kens repos - if oprah wants to modify the state of kens repo, she must interact directly with kens home-server so that it can be done atomically - the only exception here is the that code and issues can be under version control; so for that subset of actions, the sanity of atomicity being can be replaced with merge conflicts because those can be resolved manually by the user with standard tools - if you must mirror issues and PRs it is most sensible to simply have them be git repos like pagure and deal with merge conflicts manually; or else you must revert to denoting one as canonical master and losing federation "cross domain permission" should not be desirable - just do "cross domain auth" and keep repo permission on the host where the repo lives - the only thing that the standard needs to ensure is that all identities are canonical and unique across the network
again, that would be a terrible way to implement - oprah should not need to keep kens code on her home-server in order to collaborate on kens instance - oprah simply interacts with kens instance on kens home-server - kens home-server only needs to auth oprah against her home-server when she interacts with kens home-server
another terrible implementation - completely at odds with the notion of federation - federation is antithetical to hierarchy - it simply is not possible nor desirable to denote one instance as having precedence over any other - if you implement that you do not have federation - git does not have a concept of a fork - there is just replica A and replica B - "forks" are an entirely logical and optional distinction; and therefore each server is free to implement that fiction any way they like (or ignore it) - all that is required for a pull request is a destination repo and branch, and the patch to apply - any hierarchical distinction plays no role in that process
im not sure how to address that - realistically speaking, a repository absolutely "belongs" to a server - not in any logical sense, but in the strictest practical sense - the user who logically owns the repo may well have never been in the same room with that server, much less be the true owner of the hardware - just to put that into context, assuming all repos are freely licensed, it is the actual legal owner of the physical server box who actually legally owns all of the data on it - period - the software license grants that - not even the copyright holder has any claim to it - i.e. if you clone my repo from my server to your server, i do not have any permission on your server unless you grant it explicitly, and i should not - that is just a fact of reality - no protocol can speak to that, especially not when it is federated |
You are not mistaken. GitPub should not specify issue tracking at all, aside from some notification and associated semantics. It should be a protocol for federation, which ultimately means pure notification. A specification of issue tracking, however, would mean specifying application logic to be implemented by the services participating in the federation. The policy should ideally be defined by the maintainer of a project. An implementation may provide means for defining one, offer a selection of policies or, in the worst case, just implement some implementation defined policy. Imo GitPub should (only) specify means for notifying and querying facts about PRs, and maybe issues. It turns out that that's the only thing required for both federated and distributed issue tracking. As @bill-auger noted, some actually talk about notions of distributed issue tracking in this thread. In order to avoid confusion, lets define federated issue tracking as follows:
In this case, all we can do anyway is tell "upstream" that we have an issue which is somehow related to the project. How this issue is represented is (for now) another issue. Let's assume that it can at least be represented by some URI. "upstream" may nor refer to this issue from it's dashboard, track this issue by querying its state or ignoring it altogether. For distributed issue tracking, notifications is all that is required anyway. Given that the service a repo is hosted on supports a specific dit, it will "do its thing" and, for example, mirror the new information. This then becomes available to the maintainer automatically. |
|
i think more could be done that merely notifying the issue tracker that some interesting has happened - in the pagure model issues are just git repos - that inherently makes it federated - new issues and issue comments then are just a git commits that can be handled in exactly the same way as a pull request against the code repo - as no external tooling would be required for that it seems the simplest razor solution - it can be argued that the protocol should not assume the implementation but we are talking about git forges and pull requests are an intrinsic feature that needs to be specified anyways - even if not implemented as a git repo on a particular server, making a patch file of the issue in order to fake a pull request seems like very simple adaptor - in any case it would be highly desirable that entire issue sets can be completely migrated from one inter-operating git forges to another |
|
@bill-auger: So if we do federate issues and comments, can we pass along some meta data to facilitate issue hashing / patching of this sort? |
This would actually also work for git-dit. For other dits, I'm not so sure... Anyway, if we pursue such a solution, the "receiving" or "following" service must either perform a fetch, e.g. of a specified reference, or we need a stable way to reconstruct a commit with exactly the same hash. I think this is what @yookoala just noted. The former is obviously easier to do. |
|
@neithernut: I don't think we should force the implementations to support certain notion of comment / issue management (unless there is substantial supports from the stackholders, which would be the ones who develop Git service software). I'd propose to allow for additional information in the protocol that make space for underlying implementation for additional security / redundancy. |
|
i was plainly just saying an issue comment is exactly equivalent to a pull request - if the system already specifies a protocol for pull requests (and it will) then supporting issues and comments (if they were git commits) would be a feature that comes for free i will add that in the pagure model pull requests are themselves git repos as well - they are just a special case of issue that happens to be associated with the metadata to make a merge (destination repo and branch, the patch data) |
I agree. I just wanted to point out the implications of such a decision.
In this case, the question is what data should be provided by a service, either as part of a notification or when queried. This could be, for example:
|
There's a well-defined precedent here, DNS. I think it's probably important for any federated system to not rely on one specific server for anything, right? Each user on the system can have a published public encryption key (or keys) that they manage themselves and only they have the private keys for. Then, each repository is associated with one or more users, and only responds to requests that are signed with one of the users' private keys. That request can be distributed to other nodes on the federation, and could even be stored as an artifact of the history. |
|
@coderkevin
you proposed that a repository is rooted not on a server but the "name" of a person or organization. This implies the collision/reservation issue because you now have to reserve names across the federation. As for DNS, a person or organization may not own a domain name. It's actually quite rare for the persons to own a domain name. So you end up having names and organizations "managed" under the domain name of a service. You could make use of things like OpenID but I suspect that's not what you had in mind. I think having a repository rooted on a service with a given domain name is not that big of a deal, if "upstream" has to move for some reason, followers may need to have their repos point at the new upstream, but this is not a problem imo. It's rare and such "re-pointing" functionality would be provided by any reasonable implementation. Even if we don't specify a notification for moves, services could hack something using a HTTP 301 status code. Edit: I find what you jus tproposed is completely different to your original proposal btw. |
|
Well, I wasn't exactly talking about using domains for organization names. But you're right that one would have to reserve such a name across the federation. I wonder if we could use what we've learned from the DNS system. Perhaps there can be a small constellation of servers which share a consensus of a name directory. Names of organizations and users, and the associations between them...Oh and maybe the public keys for the users as well. Does this make my original proposal more clear? |
|
"names" is not the appropriate concept - it is "IDs" that must be canonical and unique across the federation - that is not to say fred42 must be unique because every identity should be coupled to a home-server - so fred42's actual ID is fred42@freds-home-server.net - the "name" fred42 only needs to be unique on freds-home-server.net |
What happens when freds-home-server.net goes down? Or if the domain expires? Wouldn't this still have a single point of failure? Who will be the authority if that one single point of failure ceases to exist? |
|
if fred's home-server goes down then fred (and fred alone) has a minor problem - if fred has previously neglected to backup his data and credentials, the fred, has a bigger problem - yet the network lives on unfettered i think you are assuming that fred's home-server is most likely to be operated by some person other than fred himself - which leads people to ludicrous suggestions like the one in #10 where it was suggested that the protocol should somehow try to prevent servers from shutting down; in order to protect users who are not in control of their own data on that server - the very promise of federation is to give users full control over their own data by running their own server in federation with the larger network of inter-operable nodes |
|
I have mocked up some draft vocabulary based on the discussions in these issues, and I think the inclusion of "Mirrors" as a concept for the Repository actor can prevent some of this problem. However, you are still at the mercy of Fred actually putting up mirrors and announcing them. |
|
"you" are never at freds mercy - fred decides when and where to publish fred's code and when to delete it - fred is not obligated to do anything; and no other person is necessarily interested in his actions - if "you" think fred's code is worth preserving more than fred does, then it is "you" who should clone and backup fred's code in case he unplugs his computer maybe this will be is called "mirroring" - maybe this will be is called "forking" - maybe this will be downloading a tarball - as long as fred's code is published, then anyone can get it, for as long as fred's code is published |
|
i still confused why all this discussion is still happening on github - the mailing list was setup this morning - it would be most helpful to have all discussions in a single venue |
|
because no one knows where the mailing list is and it's not publicly visible
…On Thu, Jun 7, 2018, 8:16 PM bill auger ***@***.***> wrote:
i still confused why all this discussion is still happening on github -
the mailing list was setup this morning - it would be most helpful to have
all discussions in a single venue
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#11 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAORV1E-RtxBuLqN364BgK65aJc_ezr9ks5t6cJSgaJpZM4Uc_hv>
.
|
|
it was not setup properly this morning - everything is working properly now the address is: this is the link to the archives: |
|
@nightpool: Sorry. My fault. @bill-auger has helped to fix it in our README.md now. Please check. Thanks. P.S. Received your mail. Also added you to the mailing list already. |
|
the mailing list is now fully functional - a thread has been started on the mailing list to continue the discussion in this issue - for those who are subscribed to the mailing list, check your email for the thread titled "issue tracking"; and reply to it to continue the discussion begun on this issue |
|
One of the reasons we PSYCers (who did a federated chat system in the 90s, then decided to drop federation) was that there was no satisfactory way to ensure that an incoming TLS connection is legitimately speaking for a certain domain name. Your server is presented a certificate from the other side and has to autonomously figure out whether it is trustworthy — nobody has figured out a way to interactively engage some user to make an educated decision. Most servers in the XMPP federation do not check certificates, for example — so anyone who wants to tear down entire issue trackers can write a bot that fakes a legitimate contributor's user@host credentials and recursively deletes all data. You can probably come up with worse scenarios — I just mention the first that came to my head. To solve the problem of X.509's untrustworthiness you can try to throw DNSSEC and DANE at it, which means that less people even have the competence to set up their own servers. Most devs won't run their own servers anyway, so they need to register with somebody else's server who then exercises a certain degree of power on them — In history, federation has always been a slippery slope towards centralization. For a truly distributed authentication that has no authority-bearing servers you'll want to authorize people by the means of public key crypto, as has been suggested already in this thread. If you take this route, then you typically need custom software on the user's machine (git commit -S might be helpful). Or there may be a solution involving HTTP client certificates to log into as many servers as necessary. From our perspective the next logical step is to organize the routing according to those public keys, removing the dependency on servers all together. Git was invented to be server-free and it should actually be possible to pursue that path. Also I recommend not to repeat XMPP's mistake of using user@host notation, as it will first create user expectation that those addresses also work for email and then produce SPAM on all protocols using that notation. Better to use a custom URL syntax. |
|
very good points @symlynX i should clarify that the user@host notation is not a "mistake" precisely, it is standard URI syntax for when you want some user-specific resource (other than a flat file in a HOME dir) to be accessible in a standard way by some generic client - HTTP, FTP, SIP, and countless other protocols have used it for that purpose - with that said, it is true that in this case, this is strictly an ID and not playing the role of a URI |
|
ActivityPub examples use |
|
but again, in this case, this is strictly an ID and not playing the role of a URI and never needs to be passed as any part of a URL - it can be any globally unique string - even unicode |
|
@symlynX: I think our federation need to support existing git service instances. And most, if not all, of them uses identity locals to the instance server. That means there is no true distributed authentication in the eco-system. I think our protocol, if possible, might allow true distributed authentication in long run. We might also solve issue for repositories migration with global identities. But even at that stage, I don't think it will be enforced. Thanks for sharing your experience :-) |
|
I think we should use an approach like Mastodon for short hand reference. The "true" user ID in the protocol would best be the HTTPS URL to the user page. |
|
it would be most helpful to keep discussions on topic - the topic of this thread is "issue tracking" there is a dedicated thread for discussions of "identity and authentication" |
|
Maybe worth looking into prior art: there is this very interesting protocol used by Hubzilla that was specifically designed for such purposes: https://project.hubzilla.org/help/en/developer/zot_protocol#What_is_Zot_ |
I would strongly avoid writing anything into the protocol related to Mastodon custom way of using ActivityPub. There is nothing in ActivityPub related to "user@host" ID's. ActivityPub ID's are always URI's. Server implementers are free to show their users a friendly name (like Mastodon does), but it should not be a part of the protocol. (will post this to mailing list too, bill ;)) |
|
Edit: This is also sent on the mailing list: https://framalistes.org/sympa/arc/git-federation/2018-06/msg00185.html Another thing to consider with using IRI's is that you can have a canonical link that is sent over ActivityPub only, which is not necessarily human-friendly (ex: A problem with any solution that bakes in username as a unique id is that it is unnecessarily restricting 2 out of 3 parts of identity. I don't recall where I read it, but if I remember right the 3 parts of identity were broken down something along these lines:
So it would be nice to use a solution that does not forbid the separation between the Logical and Social aspects of identity. |
|
Yes, I also like to have such separation here (as changing in Social aspect
had broken things with Logical aspect a lot of times before)
…--
Regards
Gilhad"
So it would be nice to use a solution that does not forbid the separation
between the Logical and Social aspects of identity.
"
|
|
Hi, just my 2 cents: I'm surprised to see issue tracking here because it seems to me not tightly related to git or software development in general. I think an ActivityPub extension for issue tracking only would be better and keep "GitPub" for git related things like pull requests. If one wants to implement both federated pull request and issue tracking he could follow GitPub for the first and the general extension for issue tracking. Pro: git based, other VCS based apps and other apps not related to software development would use the same ActivityPub extension for issue tracking. |
|
@alxlg: Thanks for the opinion. IMO, in a federated ecosystem, we are exploring how to support feature that needs by most federated instances (i.e. the software of those instances). Issue tracking is a part of most of them. So I think we bound to discuss it anyway. Whether to put it into the spec, or not, is another issue. In fact, many people did ask for such feature in previous discussion. But even if this is specified in the result specification, since how and what to implement in the spec is always optional, a feature like "issue tracking" is not forced to the software that do not need it. |
|
@yookoala maybe I should rephrase: issue tracking is not only about software development / version control systems so it should take into account more use cases. I think it would be better to have "IssuePub" for issue tracking and "SourcePub" for activities about coding like pull requests and forks. P.S. I sent my previous reply to mailing list to but it seems it wasn't approved by moderators. |
|
@alxlg: I think issue tracking, if specified in this spec, will be decoupled from pull request specification and forking specification. Naming is just a side matter. |
|
@yookoala I just hope issue tracking spec will be generic enough and not bound to version control system use case |
|
alxlg - most every aspect of the feature set has been discussed in detail on the mailing list if you are interested to read it - one of the longest discussions was about being as generally applicable as possible (the threads: "Is it really about git?" and "Generalization, of issues and in general,") |
|
@bill-auger As I said I sent my reply to mailing list but it wasn't approved by moderators, so I can't join the discussion there |
|
alxlg - you can read everything though - the URL is in the README of this repo |
|
@alxlg: I think it is nice to have a generic issue tracking abstraction so it is not bound to any VCS. The real question is how. In the current discussion, there is no concret suggestion as to how issue tracking should be dealt with. The discussion is still about principles and scope. If you have idea on how the protocol should look like, please give us your thought here. Thanks. |
|
Maybe also worth looking into this: |
Problem
@tantek has experience on Github bridging. And he has some insight about cross domain permission handling. He raised interesting point in the ActivityPub community group meeting tonight that lead me thinking of this problem. (I think @cwebber tried to raise the same point but I was too stupid to pick up.)
The same problem also applies to a PR. Do we handle it? Or do we omit it?
The text was updated successfully, but these errors were encountered: