Problem

Our URL format will always direct you to the same view: the content of the document or comment. There are several other possible "views" of a hypermedia URL.

These views should all be embeddable in documents, which means we need a reliable way to address them.

Contact View

See the person's basic information and web-of-trust details, who trusts them and who they trust.

Profile Feed

See what this person has been doing. Show all comments, documents, capabilities and contacts that this person has signed across the whole network.

Site Feed

See all activity on this site or document. The "document feed" is just a filter of this.

Solution

Add a new URL parameter called "see" or ?s=

This "See" name is proposed here because "view" would be ?v= and that already refers to the version field.

The values of the "See" query parameter are:

"content" or "main" - this is the default current view

"activity" - The feed scoped to this document and all children documents. To filter the feed to the current document, and to support other filtering, we would add more URL parameters

"profile" - The feed of what this person has signed across the Hypermedia network. This feed will also support filters.

"contact" - Their contact/profile, with web-of-trust details and social media connections one day

Because these will be normal Hypermedia URLs, we can copy and paste them into documents to embed all these views! They will be regular embeds.

Note: the embed block already has a "view" attribute which could be used to overwrite the view specified in the URL. Currently the embed block views are "card" and "content", but it would support these new ones as well.

Accessing these views would be done with some UI, perhaps at the bottom right corner of the page. This is an advanced feature because people will mostly be looking at the content that the content creators have defined, or they will use the panel. So the UI should be "out of the way" like in the footer. @Untitled Contact is working on this.

When you click on a person, you will usually go to their main view. The empty home document problem can be solved by embedding a "profile" view into the content by default. So a user will never have a blank home document- it will at least show their profile activity feed. When they edit their home doc for the first time, they can delete that feed embed, or they can change it, or add content around it.

The "feed" item would be removed from the site header. If the publisher wants the feed in their nav bar, they would include a navigation item with the appropriate link. We will stop forcing changes to the site navigation, because the publisher should be able to decide on their own navigation! If the publisher has not set up a navigation bar, the feed can be included as one of the default items.

Other Thoughts

This document does not go into detail about feed URL filtering, but we should consider it.

This proposal allows you to have two URLs for the same feed. For example, to see the feed of what bob has done on his site:

hm://bob?s=profile&filter=site:bob

hm://bob?s=activity&filter:author:bob

And in theory we could support a global feed URL like this: hm://-feed?filter=site:bob,author:bob .

We could consider hm://-feed as an alternative to the see= query parameter, or they could all be supported together.