From 8e09ee4a6072ebb0f640e943cf68413fd5cec955 Mon Sep 17 00:00:00 2001 From: realaravinth Date: Sat, 2 Oct 2021 21:16:49 +0530 Subject: [PATCH 1/3] RFC 2: rooms and events --- .../3-rooms-and-events.md | 93 +++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 rfc/2-rooms-and-events.md/3-rooms-and-events.md diff --git a/rfc/2-rooms-and-events.md/3-rooms-and-events.md b/rfc/2-rooms-and-events.md/3-rooms-and-events.md new file mode 100644 index 0000000..7ee37fc --- /dev/null +++ b/rfc/2-rooms-and-events.md/3-rooms-and-events.md @@ -0,0 +1,93 @@ +# Events and Rooms + +## Summary + +This RFC proposes a model of sharing data in the Forge Fed protocol +through a concept of rooms and events. A room can be subscribed to, +unsubscribed from and can contain nested rooms, which themselves are +fully capable as parent rooms. Events are used to describe various types +of room activity. + +The mechanism by which an interface decides to present the events of +rooms on it's managed forge is left to the discretion of the interface +implementers. + +## Requirements + +This protocol must support the following features are required for +to enable comfortable development workflows: + +- Facilitate sending and receiving patches or pull requests +- Review contributions via pull requests or patches or any other method + supported by Git. +- Take part in discussions +- Observe contributions and discussions without active participation + +Interface implementers should ensure these requirements are met and +exceptions should only be made when their forge isn't capable of meeting +the above requirement. For instance, +[cgit](https://git.zx2c4.com/cgit/about/)-SSH forge isn't capable of bug +tracking and therefore the implementer can choose to not meet said +requirement. + +## Events + +Data stored in rooms are expressed as events. Events are atomic and are +synchronised against `main forge`. Race conditions are possible when +events are first committed on non-main forges and are then committed on +the `main forge`, eventual consistency is aimed for in such cases. + +### Naming conventions + +Event values must be uniquely globally namespaced following Java's +[package naming +conventions](https://en.wikipedia.org/wiki/Java_package#Package_naming_conventions), +e.g. `com.example.com.myapp.event`. The special top-level namespace `f.` +is resolved for events resolved in the Forge Fed specification - for +instance `f.event.patch`. + +## Rooms + +Rooms are the basic channels of communication in the Forge Fed protocol. +All forge-activity should be modeled based on rooms. Rooms are +identified based on the `main forge` but all `main interfaces` should be +capable of accommodating subscribing non-native interfaces. + +### Multilocation + +Multilocation is a [multiformat](https://multiformats.io/multihash/) +identifier that self-describes the room and is capable of nesting. Each +room is identified by its unique multilocation. The format is as +follows: + +``` +/// +``` + +When a room is nested, it can have the following format: + +``` +/ +``` + +Public URL of the room is made part of this format because it might be +helpful for non-native users when events are poorly rendered on their +forge. With a public URL, they will be able to see the events in their +native environment. + +### Types + +Room type is used to differentiate rooms with different capabilities. +Types values must be uniquely globally namespaced following Java's +[package naming +conventions](https://en.wikipedia.org/wiki/Java_package#Package_naming_conventions), +e.g. `com.example.com.myapp.room_type`. The special top-level namespace `f.` +is resolved for types resolved in the Forge Fed specification - for +instance `f.room.contributions`. + +## References + +- Rooms and events are heavily inspired by the [Matrix + protocol](https://matrix.org/docs/spec/#architecture) +- Multilocation is inspired by the + [Multiformat](https://multiformats.io/) project From 3c873768335c4d80814f33991a7056d38a972d26 Mon Sep 17 00:00:00 2001 From: realaravinth Date: Sat, 2 Oct 2021 21:25:12 +0530 Subject: [PATCH 2/3] fix filename --- .../{3-rooms-and-events.md => 2-rooms-and-events.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename rfc/2-rooms-and-events.md/{3-rooms-and-events.md => 2-rooms-and-events.md} (100%) diff --git a/rfc/2-rooms-and-events.md/3-rooms-and-events.md b/rfc/2-rooms-and-events.md/2-rooms-and-events.md similarity index 100% rename from rfc/2-rooms-and-events.md/3-rooms-and-events.md rename to rfc/2-rooms-and-events.md/2-rooms-and-events.md From 4b20a355d9d8e513677cd4223a39618882acdb60 Mon Sep 17 00:00:00 2001 From: realaravinth Date: Sun, 3 Oct 2021 11:35:40 +0530 Subject: [PATCH 3/3] fix typo --- rfc/2-rooms-and-events.md/2-rooms-and-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/2-rooms-and-events.md/2-rooms-and-events.md b/rfc/2-rooms-and-events.md/2-rooms-and-events.md index 7ee37fc..e00549a 100644 --- a/rfc/2-rooms-and-events.md/2-rooms-and-events.md +++ b/rfc/2-rooms-and-events.md/2-rooms-and-events.md @@ -14,7 +14,7 @@ implementers. ## Requirements -This protocol must support the following features are required for +This protocol must support the following features which are required for to enable comfortable development workflows: - Facilitate sending and receiving patches or pull requests