You are not logged in. Log in. Or Sign up.

Federation status: See here!

NOTE: Federation is disabled on this instance!

You can test federation between the following instances:
Vervis @
HomeSharersfr33domloverProjectsvervisTickets #60

Edit this ticket

Depended by:

Depends on:

Created on 2019-02-14 by fr33domlover

Claim requests



Status: Closed on 2019-02-14by fr33domlover .

Vervis web route tree

I’m going to discuss things below, so here’s a short version of what this is about: What will URLs look like on Vervis? URLs for users, groups, repos, projects and so on.

And now comes the discussion :)

I did put thought into the current route tree, defined in the file config/routes, but it’s time to do another iteration.

Some things aren’t changing: Projects and repos are still separate entities (anytime a project can add new repos and a repo can be taken out of a project to be stand-alone, and this should happen without changing their ID URIs). And there are still sharers, some of whom are individuals, and some are groups.

The main problem I’d like to start with is what will be the ID URIs for users and groups? Other more specific things can be in separate tickets.

And there are 2 options:

  1. They’ll use the same route
  2. They’ll use separate routes despite sharing a name pool

The reason for 2 is that it makes it visible and clear in the URI, what sort of sharer is being observed.

If we pick the 2nd option, what happens to all the things under sharers in the route tree? Will they be duplicated, or do they have a single route each?

If we pick the 1st option, we may still have specific routes for groups and specific routes for people, and we need to decide which ones go to a separate section and which ones stay in the main section under sharer.

Here are some suggestions.


This is where all sharer-common stuff goes, maybe except for a few special cases. The sharer ID URIs are here, and they don't redirect anywhere else.

Some human-specific or individual specific stuff can go here. Idk if this is ever needed.

Group specific stuff, such as managing group members and roles, can go here. But it can also be under /s, for example /s/gnu/members would work if gnu is a group, and give 404 or something if it's a user.

This is where repos and projects would go.


This is like (1), except we put ~ or % in front of sharer names.

/p/PERSON - maybe not needed, put stuff under /s/~PERSON/ instead
/g/GROUP  - maybe not needed, put stuff under /s/%GROUP/ instead


This is like (1) and (2), except we don’t use /s/ because the ~ and % prefixes make it clear what we’re looking at.

/p/PERSON - maybe not needed, put stuff under /~PERSON/ instead
/g/GROUP  - maybe not needed, put stuff under /%GROUP/ instead

Actually there are another 2 variants for projects and repos. One uses “repo” and “project” instead of “r” and “p”, and the other replaces “r” and “p” with prefix characters, for example:



Now let’s do separate routes for people and groups.

/s/ACTOR - probably not needed, maybe just a few special cases here


This is okay except:


I’m going with option (1).

Custom fields


new topic
[See JSON]