The About pages packaged with installed plugins are served from the origin as normal content yet they are invisible to search. Here we consider what we might do to resolve this omission and the benefits that then accrue.
An About page is identified with a green border and additional source information in the flag's hover text.
First we must consider how about pages are different and why a site don't just add these pages to the sitemap it delivers.
About pages are made special by their rendering with a green border. This is reminiscent of browser local storage resident pages having a yellow border. The motivation for each is similar but the mechanism, different.
The server marks an About page with source metadata as the page json is delivered to the client. This "plugin" field remains present client-side so that it can be properly rendered.
"plugin": "paragraph"
Aside: Source metadata should be erased when a page is forked to a new location. Not all fork paths in the current implementation do this correctly. We have thus leaked misleading metadata into the federation page space.
# Ownership
The federation relies on readily assumed ownership when content is forked from the commons. A site owner asserts their alignment with the pages they serve. A site's domain name, flag and sitemap represent that owner.
A farm server operator retains responsibility for configuration of plugins and the About pages they possess even as other content responsibility transfers to the site owners they host.
Up to now we have considered About pages to be a resource of convenience to authors creating content that they intend to serve, not the content itself. The alt/cmd-i keystroke locates these pages while in the act of authoring. Search hasn't been a question.
When we encourage more specialized and functional plugins hosted on more author-owned servers we enter the realm of plugin as content. The MorseTeacher plugin highlights Plugin Factory limitations for exactly this reason. The About page is itself useful content in that it describes, when properly initialized, the Morse code alphabet it is about to teach.
# Mechanism
Search depends on sitemaps fetched from each site in the neighborhood and accurately reflects content available within them save for this issue of About pages. We now consider under what circumstances this should be revised.
About pages should be distributed and found in search exactly as widely as the javascript that implements the associated plugin. But see pollution below.
The client, not the server, maintains this notion of origin. The server can attach CORS headers expressing its intention, but they are interpreted by the client because only it knows origin from not.
The client should probably ask its origin for a second origin (plugin) specific map which search folds in among all the others.
The client currently asks the origin for the factory.json which defines the Factory menu. The server thus already iterates through its configured plugins to answer a similar question.
We enjoy the efficiency of cached sitemaps and would expect the same of a plugin based one. Remember that origin is not the same as owner. One could have a flash mob of visitors fetching origin-only sitemaps.
The nascent Plugmatic plugin server-side could be responsible for building and caching the plugin-only map. It runs at server start and again whenever it changes plugin complement. Core-client javascript could take a dependency on this plugin if it handled 404 gracefully when absent.
# Pollution
It is possible that one would not want About pages when they think they are searching their own content. Would we want an option, a gesture or a workflow that manages these pages as we have come to manage our neighborhoods?
Would we expect the About pages to show up in Recent Changes? This could be useful if they had recently changed, but not always.
Perhaps visiting a page with a Plugmatic inventory adds those About pages to the neighborhood. The default configuration would add pages for all plugins. A Plugmatic that has been configured for specific plugins would add only those. If you viewed several configurations then they would have to merge in some sensible way.
Now we are deviating from the 'exactly' rule above.
If I forked an About page then I would have two copies on my server. Are both accessible? What would be in the url that would distinguish them? Perhaps they are accessed through Plugmatic's server-side through a specialized read-only siteAdapter?
We currently have synonyms for the origin domain that indicate special handling: 'view', 'local' and 'origin'. About pages could fit into this scheme as 'plugin'. Plugmatic has its own path back to the server and could retrieve pages that have been occluded by a forked copy.
This general scheme of having a server-side plugin install a specialized siteAdapter could make a lot of sense. Forks should show up with twins and everything.