Federated wiki combines a collaborative publishing model with individual editing and refactoring convenience. Here we compare events present in our system to the taxonomy of Martin Fowler, et.al. post 
Both clients and servers are coded as async javascript so there is considerable use of events and callbacks which we will disregard in this discussion as mere infrastructure.
We adopt the organization of the original post. The reader will benefit from consulting it first.
# Event Notification
We see little notification across the wire. The reader clicks a link which begets a search of the page's recorded context with http requests while handling 404 errors as they occur. We poll in a prescribed order and quit when satisfied. See Collaborative Link
With a single browser tab new pages mention available sites which are then surveyed by requesting sitemaps and assembling these into a growing neighborhood of known pages, often numbering in the thousands. This spidering of the federation is again a async polling process that is repeated within each tab under the influence of browsing.
# Event-Carried State Transfer
Editing events we call actions originate in the client and are delivered to the server as they happen. This is the reverse of the flow described in the pattern. We could echo actions to subscribers who could then follow along with updates to the pages they are viewing.
_Note to self: Try this event propagation out sometime. Consider persistent connections. This is still short of OT since only one party edits._
We keep the server-side current so that no save is required upon completion. Client and server can get out of sync in difficult networking situations. We recommend refreshing the browser thus accepting the server as truth.
# Event-Sourcing
We retain in each page the contents as a collection of items we call the story and the edit event history we call the journal. The server always provides both in their entirety but clients may choose to render a prior version by replying actions up to a point. Should a full replay of actions disagree with the story, the journal is assumed to have been corrupted.
Change of ownership is also recorded in the journal as forks. One can consult a previous owner for their version of history as well as post fork updates.
We have experimented with concatenating journals as a means of merging changes. Here common prefixes would be replayed once.
One can fork a reconstructed revision from history in which case the server's copy is replaced with the shortened journal. One should be clear: the journal tells how the current page came to be, not everything it might have been.
# CQRS
We distinguish commands to the server from queries of the server. Here we departed from RESTful design early as our first command was the editing action 'move'.
The protocol by which a wiki page is edited is a decision made by the server when it, in the role of origin, delivers the appropriate javascript implementation to the browser. Federation depends only on reads and always of whole pages.
# Making sense of these patterns
We detect in the summary by Fowler that the engineering goal is to overcome distribution rather than to embrace it as a creative force. We believe that overly consistent content creates a difficult editing environment and that some slip in consistency is required for natural selection to work its magic.
.
What they don’t tell you about event sourcing. medium
Related discussion in the Secure Scuttlebutt community on tangles. web