In the context of out-there federating between writers in wiki, here we describe what a wiki neighborhood is, and how you work actively with and through it.
The general feature of neighborhoods is described by Ward in about.fed.wiki Neighborhoods
Your site accumulates a neighborhood of 'known' sites that have been visited in the current session. It appears in the right-end of the toolbar, as a series of flags. Flags in wiki - to be added xxx
Search operates within the current neighborhood. Search in wiki - to be added xxx
Recent changes can be programmed in all sorts of ways, but by default operates starting with the current neighborhood. Recent changes in wiki - to be added xxx
You can remember, install or publish a neighborhood using a roster paragraph Rosters - To be added xxx
--- Some thoughts on this limited universe posted by mike in [matrix](https://matrix.to/#/!PgjaOWKMETpwKqBtgc:matrix.org/$CqAq8I-rT7Z3WJqd6OWxweR3v3s9yWyCgNxUd_Zm8E)
Hmmnn. I'd say fedwiki isn't about 'efficient federation'. Its about **personal** maps of what matters to an investigator, automatically published openly to the web, that can be discovered by walking the tacit social networks constituted by content links. It's structural or topical. It's narrowcasting, not open-band broadcasting.
Rosters are then a handy way to assemble a working environment of helpful sites. Wiki doesn't have a 'universe', it has a neighborhood. The neighborhood accumulates as you surf, and can be installed at will, via a roster. Search only works in the neighborhood. > Not so. There is federation search of the entire known wiki federation.
Wiki is not p2p in the fediverse sense of Any-to-any. Wiki can be used p2p, in a neighborhood of sites, between mutually acknowledged creators. It has tooling for this.
Maybe p2p collaborating in wiki works like Following in Mastodon/fediverse? But wiki has no Notifications and no inboxes. Me, I love this tacitness of peer relationships, and the pull-not-push rationale. Very quiet and companionable 🙂