Use Federated Accounts for Login

Hello -

I posted this as a ticket on Vervis, but thought it might be good to bring over here for discussion as well. I’m not sure how feasible or viable this idea is, so I’d love to get feedback on it.

One of the things I’ve had issues with in terms of Federation is that I have to have completely separate accounts for every type of instance I want to upload. I have one for Mastodon, I’d need a separate one for PeerTube to upload videos, and now a separate one for an ForgeFed instance. The idea is this: When someone registers to be a sharer, they can register using a pre-existing federated account, which would be authenticated by requiring me to log in to the federated account via OAuth2. Then my Sharer account on Vervis would be set up to point inbox/outbox and other related links in the Sharer record to my federated account instead of to a local Sharer account, meaning the federated account will manage my inboxes and whatnot for me, but I can still create projects and repositories on a ForgeFed instance.

Thoughts?

there are actually two unrelated aspects to that proposal

  • federated authentication
  • honoring proxy requests from foreign inboxes

the first part (federated authentication), has been an essential design goal, since the beginning

from the original requirements document:

  • transparent authentication and collaboration across federated instances
  • users should never need to trust any server in the network other than their home-server
  • users can interact with foreign repos in all of the typical collaborative ways just as if they had an account on each foreign host
  • users can send merge requests, open issues, post comments, subscribe to updates, and “star” repos without logging in to the foreign host

… and these, more critical prescriptive requirements:

  • server instances will verify and vouch for the identity of it’s users using the server SSL signature
  • participating hosts validate the identity of foreign users against that user’s home-server

the signature could be something other than SSL; but all that only works, if there is a known, publicly verifiable, shared authentication protocol, between the authenticating service and the other, which it chooses to trust - if any two services do not support exactly the same authentication protocol, then they are incompatible for that purpose - there are only these general possibilities:

  • no authentication - allow everyone to interact with the system anonymously
  • convince every activity-pub-based service to support the same authentication protocol as forge-fed
  • make forge-fed compatible with the authentication protocols of every and all other activity-pub-based services, even those which are not publicly verifiable
  • require a real account with a real inbox on some forge-fed compatible forge, to be designated as one’s home-server - although that could be any forge-fed instance on the network; it is ideally, one’s own self-hosted instance

in the context of software development, the first option (no authentication nor verification) is undesirable for multiple reasons - in the absence of some standard authentication protocol for activity-pub-based services, only the latter option is practical

any attempt to accommodate foreign users from services which are not forge-fed compatible, would necessarily entail some form of second-class user, with severely limited privileges on any forge; because such users could not be represented uniquely in any forge database - the range of interactions would possibly be limited to no more than the ability to post unverified (essentially anonymous) comments - in order to use all of the features of a forge-fed compatible forge, one must have a real account setup on some forge-fed compatible forge, designated as the home-server forge, which vouches for the authenticity of its users, and handles changes to the federated state, using the local database as the canonocal source of truth - that is because nothing of practical significance can happen, unless it is represented in the forge database, and attributed to a user which also has some verifiably unique representation in the database

also FWIW, some forges admins may choose to exclude that class of unverifiable user from interacting with their server in any way - such a user is practically not much different from being totally anonymous and un-authenticated - in any case in which a server allows posting from people, which that server can not verify (or block) for itself, that is an invitation for spam - an admin in that position would have not choice but to block all users for which that foreign server is vouching for their identity

so, capability authorization aside, even the authentication would not be valuable for it’s own sake, unless the foreign service supports exactly the same authentication protocol as forge-fed expects; and that is done in a publicly verifiable way (such that there are no posers or legitimate ID collisions) - it has not been yet decided, exactly which mechanism that will be; but it could be something that other activity-pub-based services do not currently support, such as reclaimid or hubzilla - regardless, without a home-server forge, many or most of the common forge-related operations, would be impossible, such as: forking a repo, pressing the “favorite” button, notifications of @mentions in comments, signing and verifying commits and comments

the second part of the proposal, that is, for a forge to act upon requests to an inbox, which is actually hosted on some foreign server (under the authority of the foreign host), would be either impractical, unreliable, a security vulnerability, or all of those - unlike the typical activity-pub messages, which have no tangible side-effects, forge-fed uses activity-pub as an API to the inner state of the server - all messages to a forge-fed inbox are intended to trigger a modification to the server’s database, which will be the canonical representation of the historical activity on that repo - furthermore, these messages are much more important than casual chat, which is the typical use for activity-pub - some forge-fed messages will represent software that people will execute on their computers - the server needs to be able to verify each user’s authenticity independently, or the admins (and by extension, the software maintainers) would be attesting to those foreign user’s actions fallaciously and irresponsibly - again, it is a design goal that third-parties manage the authentication mechanism, but that must be done in a way that is publicly verifiable - servers can not simply trust any third-party implicitly, to modify its state

AFAIK, it would require support in the code-bases of both the forge and each login service, in order to even make it possible, let alone secure - if that login host is not a forge, then one would still need to have an inbox on some forge; which is actually that user’s home-server for the purpose of all forge-related interactions; because only a forge can actually handle those requests

such a proxy quasi-home-server (be it mastodon, peertube, whatever) would need to forward its inbox messages to the inbox on the true home-server forge; where the request could actually be handled - so, someone would need to add some code to each of those other server softwares, endowing them with that behavior (forwarding its inbox to another host); and then, only instances which have that code change would be compatible - people who only use some upstream dicker binary, for example, may never get that capability, nor be able to install it - its also not clear, on the face of it, why anyone would ever send any forge-related messages to the inbox on some server which is not a forge - the use-case seems very small

it would be every bit as reasonable to propose to peertube, mastodon, or your favorite other activity-pub service, to honor logins from forge-fed forges, and to honor messages to an inbox hosted on the forge - the use-case is the same in either direction

the essence of the use-case suggested by the second proposal, is to aggregate, merge, or reroute separate activity streams to and from arbitrary services, which separately track unrelated activities - perhaps that is a desirable use-case for some people; but that suggests to me, some other new software project, which could be written to manage/mediate activity streams in a general and service-agnostic way - it is not something that any one specific service should need to support generally

1 Like

Thank you so much for your thorough reply. Very enlightening!!

I understand where you’re coming from on the first part. Given your explanation on authentication capabilities, I could concede why a separate account would need to be made, especially if authentication methods between the ForgeFed server and the other federated server are incompatible.

It seems like you weren’t quite understanding where I was coming from on the second part. Let me try to explain differently: It may be that I just don’t thoroughly fully understand the specs yet, but it was my impression that the actions you spoke of (“rigger a modification to the server’s database, which will be the canonical representation of the historical activity on that repo”) would happen in the inbox and outbox of the project and/or repo, which would still be stored in the local database, and that the Person’s inbox/outbox would be more for sending messages back and forth, more like chat. Because of this, the thought process would be to direct the Person’s messages to their other federated account.

In addition, the thought wasn’t that there wouldn’t be a local account at all for the Person. They would still need the entries in the database, which would still allow for authentication and validation by other ForgeFed servers. BUT, the inbox/outbox uris/urls listed in the local database would point to the remote account on Mastodon/Pleroma/etc., so that the Person receives those messages on the remote account instead of having to log on to the forge’s Person account to see what is happening there. Again, the understanding behind this idea is that the Person’s inbox/outbox would not be used for actual repo work (my understanding is that the Repo’s actor would serve that purpose), rather would just be used for notifications on actions of projects/repos that the Person is following (including their own), e.g. Merge Requests, pushes by other Actors, someone opening a ticket, etc. I’ll try to look through the specs again to see if my understanding is incorrect. If you happen to know the answer to that, I’d love to hear that as well.

That being said and assuming my understanding is correct, that type of message redirection could still be possible while still requiring a local login, though it’d have to be a user configuration setting instead of a default registration idea.

Anyway, thank you again for the comment. I’m interested to hear your thoughts on my updated musings as well. Have a great day!!

Ok, further thought process on this, since I’ve been passively stewing over this while working…

To be clear on this thought before I get started, the assumption on the below musings is that unverified updates would only be allowed for comments, tickets, and anything more communication related. Pushes to the repo, Merge Requests, anything to do with the actual code itself would always have to be verified. Ok, with that out of the way…

Directing notifications to your remote inbox is one thing, and I think that can/should be doable, but the concern then would be if someone wanted to respond from the remote account (e.g. to a ticket notification and have the response be posted as a ticket comment), then we would potentially have issues when it comes to verification of the user, as Mastodon/Pleroma/etc. most likely will not have the right verification tools in place to complete the verification process.

For servers that allow for unverified comments/tickets/etc., that wouldn’t be an issue at all, but it would be an issue for those that do not allow for unverified comments/tickets/etc., so the experience would be different depending on which project you want to respond to.

I’m not sure I have a thought/solution for this part, at least not a viable one. I’m more just putting it out there as part of my brainstorm for now. If I have more thoughts on it later, I’ll post them as I think of them.

activity-pub is not chat platform - if that is the impression that people have, then perhaps it is unfortunate that mastodon became the most notable activity-pub based service - the intended use for activity-pub is activity feeds (aka: activity streams) - they are nothing different from RSS or ATOM news feeds, except that they are not written by a person, but are auto-generated by a server when certain interesting events happen - if you are familiar with github, it is exactly like the list of activities on your dashboard page - a linear history timeline, with very brief descriptions of actions that have happened in some context - in the context of forges, that would be something like,

timeline for repo ‘foo-repo’:

  • alice opened a pull request against foo-repo
  • bob added a comment to issue #42 of foo-repo
  • charles started watching foo-repo

timeline for user ‘alice’:

  • alice opened a pull request against foo-repo
  • alice “likes” bob

timeline for user ‘bob’:

  • bob created bar-repo
  • bob added a comment to issue #42 of foo-repo
  • bob started following charles
  • alice “likes” bob

generally, those feeds could be subscribed to by anyone with a compatible reader, just like RSS or ATOM news feeds - it is possible to build a chat/forum/blog platform upon activity-pub (or any network protocol); but it not the ideal tool for that job

regarding forge-fed, i do not know of any forge which has chat or blog features - therefore, there is no reason to assume that forge-fed would support chatting or blogging - on forges, all messages carrying arbitrary text, are associated with specific tickets, which are associated with specific repos, and they exist as items in the forge database, as do the tickets - people would not send arbitrary messages to a forge inbox, such as they may on a chat platform; because forges have no way to store or present anything arbitrary - conversely, it makes no sense to pass around the body of ticket comments to any other service which is not a forge - if the comments are not to be represented in exactly the same original context (a discussion on a ticket against a source code repo), then they would be “free-floating”, out of context, and either useless or confusing at best - as you noted, if someone tried replying to one of them, the reply would not make it on to the forge anyways, so the reply would be quite pointless, and invisible to the project maintainers

other than a small subset of forge-fed messages, forge-fed is using activity-pub in a very different way than what it was intended for - if you are familiar with the term “API”, forge-fed is nothing more than that - it is an API for forges to interact with each other - the core forge-fed functionality does not involve people - people interact with their home-server forge, in the normal expected “mouse-clicking” ways, just as any existing forge - IFF some interaction involves a repo which is hosted on another forge, then the local forge software communicates with the remote forge using the API, on the local user’s behalf - that happens transparently to the user; and it is uninteresting to the user, that activity-pub is involved in that process - the API could be plain XML or JSON over HTTP protocol, email, gofer, or any other network protocol - the fact that activity-pub is used is quite irrelevant for the most part

the reason why activity-pub was chosen, is that it has the property of compatibility with other fediverse services; for the small subset of the API which those services could produce or consume: eg: activity notifications such as above, and perhaps replying to comments on existing tickets - most of the forge operations would not make sense to be initiated or handled by a service which is not a forge; so it would be useless to send all forge-fed messages to an inbox that was not controlled by a forge - a mastodon inbox would not be able to handle a ‘fork-repo’ or ‘open-pull-request’ message - note that those examples are not notifications of events: eg: “alice opened a pull-request” - those are requests for something to happen, eg: “alice wants to open a pull-request - can this server do that for her?” - IFF the server did decide to fill that request (it does not need to), then a different notification message may be sent to subscribers indicating that it happened (and it does not need to do that either)

OTOH, to receive notifications on your mastodon home-server, of activities which were handled by a forge, is exactly the use-case which made activity-pub a convenient choice for the protocol - that is already one of the design goals; so nothing new needs to be discussed, in order to accommodate that use-case - one simply subscribes to a repo or user feed (follow, watch, whatever the terminology), just the same as any other mastodon user or hashtag or whatever - but unlike a chat/forum/blog platform like mastodon, no one would ever be able to send an arbitrary chat message to your inbox, such as “hello, how are you doing today?”; because there is no forge-fed messages like: ‘random-chat’ or ‘personal-message’, which would handle it - all forge-fed message correspond to requests for the forge to do something, which it is already capable of doing - that “something” could be “add this text as a comment to ticket #42”; because that is something that forges can do already - but if forges do not have a chatting or private messaging feature, then there would be no forge-fed message to describe it; because the forge would not be able to handle it anyways

the activity-pub inbox/outbox on the forge, is of little significance to any person - if it nothing more than a listing of your historical interactions - perhaps that activity would be interesting to others; but if your only interactions are replies to ticket comments for example, then your forge timeline would be nothing more interesting than such:

  • “jason posted a comment to foo-project ticket #42
  • “jason posted a comment to bar-project ticket #43
  • “jason posted a comment to foo-project ticket #42

anyone subscribed to your forge activities timeline, would receive exactly each of those as they happen - however, the text body of the comments would not normally be represented on the timeline; though perhaps each entry would include a URL, which could be used to visit the post on the forge website - this is how i understand activity-pub anyways - mastodon extends activity-pub to do something beyond its intended purpose. namely chatting and blogging - forge-fed extends activity-pub to do something very different, which is also beyond its intended purpose. namely interacting with a forge - but there is no more reason for forge-fed to support chatting, than there is for mastodon or peertube to support forge interactions

mastodon, peertube, and forge-fed are very different tools for very different jobs - they just happen to use the same network protocol, which can be useful in the few limited cases where they can represent the same information or handle the same interactions; but the intersection is quite small - forge-fed is fundamentally only a mechanism for one forge to ask another forge to do something, on behalf of it’s local users, in order to simulate that every user of every forge-fed compatible forge, had an account on every other forge - i can understand the use-case of sending notifications, of events which happened on a forge, to a mastodon stream; but most of the forge-fed messages would impossible to satisfy or even to invoke from some service which is not itself a federated forge; because they would not carry the relevant context necessary to handle them

again, i invite you to read the original requirements document - that describes most plainly and clearly, what forge-fed is - you can completely ignore the fact, that it was eventually decided, that those requirements would be satisfied using activity-pub as the communications protocol - the communications protocol could have been anything; but activity-pub does allow event notifications to be consumed by other unrelated services, in a conventional way