Frontend and UI #8
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As I mentioned at the July federation meetup, the UI for federated features is a huge challenge. Currently, I have some Ruby scripts and hand-write ActivityStreams objects, but that's tedious and error-prone. Since designing and implementing the UI will be time-consuming, I think we should start now.
Fortunately, we have a secret weapon: Gitea already has a fully-featured UI for local actions. Since the goal of federation is to use one account across all instances in a seamless way, federated features should overall have a very similar UI as the local version of the feature. For instance, opening a pull request on a remote repo should feel almost the exact same as opening one locally. Of course, there are some situations where the local and federated version of the feature will be different, but overall, we aren't starting from scratch but already have a lot to work with.
So, my idea for implementing the UI is to lazily reuse the existing UI for most features, but add the federation handling into internal functions. For instance, the
issues.CreateCommentCtx()internal function is used to create issues and used by the web UI and API. If we add some additional code inside that function for when the target repo is a remote repo (i.e. its owner has@in their name), then opening an issue on a remote repo will work perfectly without any other changes. (One small detail to worry about is if the remote instance is down, in which case creating the issue should fail).For rendering remote users, orgs, and repos, I propose again that we can reuse the existing UI, and add a link on those pages to the remote instance, like what Mastodon does:
We will also need an
/authorize_interaction?uri=endpoint since this is what other AP software use. When this endpoint is given a URL of a AS object, it fetches the object and renders it on your instance. For instance, if Alice has an instance at alice.com and goes tohttps://alice.com/authorize_interaction?uri=https://bobert.com/api/v1/activitypub/user/bobert, it should fetch Bobert's account's Person object, then redirect Alice to https://alice.com/bobert@bobert.com where Bobert's remote account is rendered as I proposed above. We could even include a text box somewhere where users can paste in the URL of a remote user and then are redirected to the/authorize_interaction?uri=endpoint, similar to how in Mastodon, you can paste a URL into the search bar and Mastodon will render the remote AS object.The final piece of the puzzle is to display UI buttons like follow, star, fork, etc on Gitea when you are not logged in. The purpose of this is for when you are browsing a user or repo on a remote instance. When you click the UI buttons, a pop-up box should appear that instructs you to type in your instance, and then you are redirected to the
/authorize_interaction?uri=endpoint.There are also some additional federation-specific UIs that we should consider implementing: blocking or reporting users/content and user/organization migrations.
Once we implement all of these components above, Gitea will finally have a usable UI for federated features! ?
However, this is probably not the optimal UI. @dachary conducted some user research last year that might be useful for finding ways to improve the UI and UX. Since the local and federated versions of the UI will be similar, it's likely that some problems with the UI will apply to both the local and federated version.
You've clearly been putting a lot of thought into this, which is great to see, and I like your approach.
A few thoughts:
I agree with this 100%. The less difference between interacting with an repo on a remote instance and interacting with a local one, the better.
This is not strictly right; that URI isn't standard and or hard-coded. Each AP software has their own URI. It's advertised over WebFinger as the
templateproperty of alinkwith arelofhttp://ostatus.org/schema/1.0/subscribe.Examples (links are to WebFinger URLs):
/authorize_interaction?uri={uri}/pub/remote_interaction?acct={uri}/authorize-follow?acct={uri}/remote-interaction?uri={uri}template(probably because it doesn't have a web UI)templateWe can pick our own path for this and advertise it via WebFinger.
This is great for people. What about organisations? Would it be just the same? I guess there's no reason why it shouldn't.
I would suggest that rather than a new search box, this should work with the existing search box at
/explore/repos.(I'd also argue that that search box should be visible in the global nav bar, not just at that URL, but that's a generic Gitea UI issue rather than being specific to federation.)
That's all I have for now, but I'll think about this more as I get a chance and come back with any ideas I think of.
There is also the issue (as briefly discussed on Matrix this morning) of how remote repos are represented, as opposed to just remote accounts.
I guess that following on from the idea of
https://alice.com/bobert@bobert.com, Alice could see and interact with Bobert'sfoorepo via something likehttps://alice.com/bobert@bobert.com/foo.I like PeerTube's remote subscribe UI (a small overlay on the page) much better than Mastodon's annoying pop-up window:
Yes, strictly speaking we are free to choose any path we want for this, but I just arbitrary chose
/authorize_interaction?uri={uri}. The only potential problem this could cause would be if someone had the username authorize_interaction, but I doubt that's going to be a problem.Right, we can use the same process for organizations and repos as well.
Good idea! I also agree that there should be a global search bar, but as you said it's a general UI issue.
The challenge with remote repos is that we need some degree of data duplication, but not too much. For instance, if Alice has a repo hello-world on alice.com and Bobert to bobert.com, alice.com shouldn't also store a copy of Bobert's fork since if hello-world is a popular repo, it might be forked thousands of times and alice.com would probably run out of disk space. Even if Bobert sends a federated PR back to Alice, it's better to use AGit instead of actually copying Bobert's repo to alice.com, since large projects with tons of contributors with also eventually run out of disk space.
We will be rendering remote repos, but they'll probably show up as empty on your instance with a text box telling you to go the original instance. This is because our only options for interacting with a remote repo where you don't have a local copy are iframes (terrible idea) or using the Gitea API. It's simpler to just have the user go to the original instance (and that's also what Mastodon does in the image I sent in the first post).
Since v4.0, Mastodon no longer uses pop-up boxes for redirecting you to the your instance. Instead, it asks you to copy and paste the remote object URL into your instance's search bar. This would require us to
https://to the/authorize_interactionendpoint.