update rfr-1; add gitignore

.gitignore

@@ -0,0 +1,6 @@
+_site
+.idea
+.DS_Store
+.jekyll-metadata
+.sass-cache
+.jekyll-cache

Gemfile.lock

@@ -0,0 +1,82 @@
+GEM
+  remote: https://rubygems.org/
+  specs:
+    addressable (2.8.6)
+      public_suffix (>= 2.0.2, < 6.0)
+    colorator (1.1.0)
+    concurrent-ruby (1.3.3)
+    em-websocket (0.5.3)
+      eventmachine (>= 0.12.9)
+      http_parser.rb (~> 0)
+    eventmachine (1.2.7)
+    ffi (1.17.0-arm64-darwin)
+    forwardable-extended (2.6.0)
+    google-protobuf (3.25.3-arm64-darwin)
+    http_parser.rb (0.8.0)
+    i18n (1.14.5)
+      concurrent-ruby (~> 1.0)
+    jekyll (4.3.3)
+      addressable (~> 2.4)
+      colorator (~> 1.0)
+      em-websocket (~> 0.5)
+      i18n (~> 1.0)
+      jekyll-sass-converter (>= 2.0, < 4.0)
+      jekyll-watch (~> 2.0)
+      kramdown (~> 2.3, >= 2.3.1)
+      kramdown-parser-gfm (~> 1.0)
+      liquid (~> 4.0)
+      mercenary (>= 0.3.6, < 0.5)
+      pathutil (~> 0.9)
+      rouge (>= 3.0, < 5.0)
+      safe_yaml (~> 1.0)
+      terminal-table (>= 1.8, < 4.0)
+      webrick (~> 1.7)
+    jekyll-feed (0.17.0)
+      jekyll (>= 3.7, < 5.0)
+    jekyll-sass-converter (3.0.0)
+      sass-embedded (~> 1.54)
+    jekyll-seo-tag (2.8.0)
+      jekyll (>= 3.8, < 5.0)
+    jekyll-sitemap (1.4.0)
+      jekyll (>= 3.7, < 5.0)
+    jekyll-watch (2.2.1)
+      listen (~> 3.0)
+    kramdown (2.4.0)
+      rexml
+    kramdown-parser-gfm (1.1.0)
+      kramdown (~> 2.0)
+    liquid (4.0.4)
+    listen (3.9.0)
+      rb-fsevent (~> 0.10, >= 0.10.3)
+      rb-inotify (~> 0.9, >= 0.9.10)
+    mercenary (0.4.0)
+    pathutil (0.16.2)
+      forwardable-extended (~> 2.6)
+    public_suffix (5.0.5)
+    rb-fsevent (0.11.2)
+    rb-inotify (0.11.1)
+      ffi (~> 1.0)
+    rexml (3.3.0)
+      strscan
+    rouge (4.2.1)
+    safe_yaml (1.0.5)
+    sass-embedded (1.69.5-arm64-darwin)
+      google-protobuf (~> 3.23)
+    strscan (3.1.0)
+    terminal-table (3.0.2)
+      unicode-display_width (>= 1.1.1, < 3)
+    unicode-display_width (2.5.0)
+    webrick (1.8.1)
+
+PLATFORMS
+  arm64-darwin
+
+DEPENDENCIES
+  jekyll (~> 4.2)
+  jekyll-feed
+  jekyll-seo-tag
+  jekyll-sitemap
+  webrick (~> 1.7)
+
+BUNDLED WITH
+   2.5.11

_posts/RFRs/2024-06-15-rfr-1.md

@@ -1,14 +1,10 @@
 ---
 layout: post
-title: rfr-1
+title: RFR-1
 published: true
 ---
 
-# RFR-1: CRO Snapshot
-
-Note: RFR standards for **Request For Research**. Its purpose is to reify (make explicit) a research problem and its expected outcome. One benefit of doing so is RFRs can be open to external contributions.
-
-This is the very first RFR. Let’s evolve the format of RFR over time.
+Note: RFR standards for **Request For Research**. Its purpose is to reify (make explicit) a research problem and its expected outcome. This is the very first RFR. We will be evolving the format of RFR over time.
 
 ### Title
 
@@ -18,9 +14,7 @@ CRO Snapshot
 
 The first paragraph of [Chandy & Lamport’s paper (1985)](https://lamport.azurewebsites.net/pubs/chandy.pdf) outlines the problem of taking a global snapshot of a distributed system:
 
-> Processes in a distributed system communicate by sending and receiving messages. A process can record its own state and the messages it sends and receives; it can record
-nothing else. To determine a global system state, a process p must enlist the cooperation of other processes that must record their own local states and send the recorded local states to p. All processes cannot record their local states at precisely the same instant unless they have access to a common clock. We assume that processes do not share clocks or memory. The problem is to devise algorithms by which processes record their own states and the states of communication channels so that the set of process and channel states recorded form a global system state. The global-state-detection algorithm is to be superimposed on the underlying computation: it must run concurrently with, but not alter, this underlying computation.
->
+*Processes in a distributed system communicate by sending and receiving messages. A process can record its own state and the messages it sends and receives; it can record nothing else. To determine a global system state, a process p must enlist the cooperation of other processes that must record their own local states and send the recorded local states to p. All processes cannot record their local states at precisely the same instant unless they have access to a common clock. We assume that processes do not share clocks or memory. The problem is to devise algorithms by which processes record their own states and the states of communication channels so that the set of process and channel states recorded form a global system state. The global-state-detection algorithm is to be superimposed on the underlying computation: it must run concurrently with, but not alter, this underlying computation.*
 
 Every CRO (conflict-free replicated object) can have multiple replicas progressing asynchronously at the same time. Each replica holds a collection of updates (equivalently: a local history of the CRO), either generated locally or generated by other replicas and delivered over the network. A CRO snapshot is a singular collection of updates that represent the *current state* of the CRO.
 
@@ -53,11 +47,9 @@ We have received multiple validations on the following idea towards an algorithm
 
 ### Related works/projects
 
-DXOS / https://dxos.org/
-
-Anytype / https://doc.anytype.io/anytype-docs
-
-Automerge / https://automerge.org/
+- [DXOS](https://dxos.org/)
+- [Anytype](https://doc.anytype.io/anytype-docs)
+- [Automerge](https://automerge.org/)
 
 ### Timeline