![[Home]](/static/logo.png){kind=logo}
NearRecentChanges is an idea that helps people on one wiki see what’s happening on another wiki. When the first group of people looks at their RecentChanges page, they would also see not only their own changes, but their neighbors’ changes as well.
Why would anyone want to do this? Don’t we want to be focused on our own thing? Can’t people who are interested in what’s going on in their own place look on their own? These are good questions, and I’ll try to advocate for NearRecentChanges in my response.
Why would anyone want to do this? Suppose you have a group of people assembled around one wiki. They start to have a conversation about copyright licenses. It’s essential to these people that the conversation takes place, because they need to license what they write. But it’s not really part of what the wiki’s about- this is a wiki about community, not copyright licenses.
So, what can they do? What can they do, to avoid filling their wiki about community with pages about the nuances of copyright law?
They can: 1. Create a new wiki, or find an existing wiki, about wiki copyright law. 2. Set their RecentChanges page to watch the wiki copyright law wiki. 3. Post ideas about the wiki’s copyright law to the new wiki. 4. When the issues have been debated and a conclusion has been reached, shut off the NearRecentChanges. They are now two distinct wiki.
NearLink is a related idea, that would work well with the NearRecentChanges.
Basically, NearLinks make it so that if you use a link that appears on a neighboring wiki, that you don’t have to preface the name with an InterMap entry.
So, instead of writing WikiFeatures:NearRecentChanges, you can just write NearRecentChanges. If WikiFeatures is in the wiki’s list of nearby wiki, then the link “just works.” You don’t have to explicitly say on what wiki the page is found on.
Some form of community government (WikiFutures:IdeasToPlace, #20) may be required to help determine what to include or exclude from the RecentChanges page.
Why not have just every individual use their own ChangeAggregator? Because there is some form of consensus reality that needs some maintenance for the clique to be what it is. Imagine if there was no such thing as a RecentChanges page- everyone just subscribed to the individual pages that they were interested in. There would cease to be the clique that develops from exchange facilitated by RecentChanges- seeing what other people are doing.
RecentChanges is (for better or worse, good or evil) forced observation.
OddMuse, which has implemented NearLinks, has a page titled “RecentNearChanges,” which shows recent changes on all wiki on the Near``Map. (The NearMap is used to resolve NearLinks.) However, you can’t turn them on or off, nor are they incorporated into the main RecentChanges list, and you can’t tell (yet) what updates are coming from what wiki.
| status | wiki engines |
|---|---|
| Implemented | - |
| Developing | - |
| Intend to Develop | - |
| Considering | - |
| Rejected | - |
The feature requires the cooperation of two wikis: One wiki is watching another. We’ll call the wiki that is watching the “observer,” and the wiki that is being watched, the “subject.”
The observer needs code that lets it look at a subject. The observer looks at the subject, and reads the recent changes on that subject. Then, the observer incorporates those recent changes into it’s own list of recent changes. It mixes the two up, but leaves some notes about which come from the observer, and which come from the subject. That way, readers can tell which is which. It’s pretty simple.
The subject needs code that lets other wiki look at it. It’s one of the MachineServices for wiki. That is, it needs to do so in a way that’s standard across all wiki. Every wiki has a different way of drawing the RecentChanges page for users, but machines need a single, standard way of communicating to each other. So the subject needs a way to tell the observer what’s changed, in a way that the observer will understand.
The good news is, the subject’s half is already done! There are two technologies that wiki use to communicate what is happening locally: RssPublication, and the XmlRpcWikiInterface. Briefly, RssPublication publishes the contents of the RecentChanges page for ChangeAggregators- software that humans use to watch a lot of wiki and blogs at the same time. The other- the XmlRpcWikiInterface- is more specifically for wiki. It’s intended for programs and wiki to be able to observe wiki, and learn more in detail about what’s happening on a wiki.
observer - a wiki that is taking another wiki’s recent changes (the subject wiki), and reporting on them.
subject - a wiki that is being observed by another wiki (the observer wiki).
This idea is called MeatBall:UnifiedRecentChanges on Meatball. That’s a pretty well known site, and it’s good to use known names.
On the other hand, the idea is related to the NearLink, and I like consistent names. Does anybody have any thoughts on the matter?
There’s the question of whether to observe RssPublication, or to use the XmlRpcWikiInterface to see what’s happening.
There’s also the question of what to do when you’re watching a wiki that’s watching a wiki. That is, if A is watching B, and B is watching C, does A also note changes on C?
I suspect that these problems may be related. RssPublication seems to be intended to communicate the contents of the RecentChanges page. If RSS is being used, then, anything that shows up on the RecentChanges page. That would include changes on nearby (but foreign) wiki. But if the XmlRpcWikiInterface were being used, I would suspect that changes on nearby wiki would be ignored, since the XmlRpcWikiInterface is talking to one particular wiki in detail.
It is conceivable that XmlRpcWikiInterface could be amended so that wiki could report on what wiki they are observing.