A symmetrical link joins two or more places without preference for one over the other. The hypertext link provided by the anchor tag in html is notoriously non-symmetrical. Here we consider alternatives not based on the html anchor.
Gregor et al (1999) 
identify some problems with links inside the document
This makes it impossible to link from legacy or non-hypermedia applications, documents on CD-ROM or those owned by other people (Andrews, 1996; Bieber et al, 1997). The absence of this ability makes it difficult to implement personal annotations which are thought to be a basic right for hypermedia readers and a basic tool for collaboration and exchange of ideas (Bieber et al, 1997). Enabling annotations and allowing Web information systems to be used for communication and cooperation will help increase the systems success (Andrews 1996). Maintaining external link bases enables such services as link and view customization, guided tours, trails, bi-directional links, link typing, individual access permissions and guaranteed consistency (Bieber et al, 1997).
# Paragraphs
Three federated wiki pages that shared paragraphs with the same id, possibly copied from a now forgotten source, and now edited to be quite different, could be said to be symmetrically linked.
Paragraphs that share ids do not imbed within them knowledge about how to find each other. Some external store, a link repository say, holds that knowledge.
Pages identified by a common slug are similarly symmetrically linked. We exploit this commonality when we identify twins in the neighborhood.
A recursive search of the federation could build a link repository based on ids that story items already have. This would not connect items that are related but not visible to the search.
# Link Store
A federation search engine doubles as a symmetric link store. See Hover Relations for more ways wiki already supports this functionality.
Items that do not share the same id could be linked by adding both ids to a third store that could be consulted by either item to find their companion.
A recursive search of the federation could build a link repository based on item ids that somewhere share a page. If one wanted to link to previously unrelated items they could then simply drag both to a new page within which they would now be associated. This makes the federated wiki page serve as the external link store for unrelated items.
A recursive search concentrates knowledge of the page storage mechanisms in the search engine. This could be to our advantage when the federation spills out into alternative networks like NDN or IPFS.
A recursive search introduces a delay that would not be present with a push mechanism like Wikimention
Also see Link Store
# What Links Here?
It should be possible for the client to discover what links to a page, in the current neighbourhood.
To do this the client needs to be able to query a site, as it is added to the neighbourhood, and retrieve the details of the page links contained on the pages on that site. This should be in the form of a map from a page to a list of pages that link there.
{ "pageName": ["linkedFrom",...] }
The creation of this link data could be part of a distributed future for the federation search engines.