@@ -9,13 +9,14 @@ Hall's implementation is structured according to the new Gall model. Familiarity
10* [Introduction](#introduction)
10* [Introduction](#introduction)
11* [Structures & functionality](#structures--functionality)
11* [Structures & functionality](#structures--functionality)
12− * [Partners](#partners)
12+ * [Circles](#circles)
13 * [Messages](#messages)
13 * [Messages](#messages)
14 * [Participant metadata](#participant-metadata)
14 * [Participant metadata](#participant-metadata)
15 * [Configurations](#configurations)
15 * [Configurations](#configurations)
16 * [Stories](#stories)
16 * [Stories](#stories)
17 * [General use](#general-use)
17 * [General use](#general-use)
18 * [Federation](#federation)
18 * [Federation](#federation)
19+ * [Public membership](#public-membership)
19* [Interfaces for applications](#interfaces-for-applications)
20* [Interfaces for applications](#interfaces-for-applications)
20 * [Interactions](#interactions)
21 * [Interactions](#interactions)
21 * [Queries, prizes and rumors](#queries-prizes-and-rumors)
22 * [Queries, prizes and rumors](#queries-prizes-and-rumors)
@@ -36,25 +37,18 @@ Hall's implementation is structured according to the new Gall model. Familiarity
37Talk was Urbit's first big user-facing application. It continues to enjoy a prominent role in the Urbit landscape, but does so as two separate applications this time.
38Talk was Urbit's first big user-facing application. It continues to enjoy a prominent role in the Urbit landscape, but does so as two separate applications this time.
39−The messaging parts of talk have been separated from its user interface parts. What we ended up with is a shiny new generic messaging bus, and the chat interface we all know and love. The messaging bus, which should now prove useful to many different applications, will be named `Hall`. Applications that use it are referred to as Hall *readers*. One such application, as you might have guessed, is `Talk`.
40+The messaging parts of Talk have been separated from its user interface parts. What we ended up with is a shiny new generic messaging bus, and the chat interface we all know and love. The messaging bus, which should now prove useful to many different applications, will be named `Hall`. Applications that use it are referred to as *clients*. One such application, as you might have guessed, is `Talk`.
42## Structures & functionality
43## Structures & functionality
44−### Partners
45+### Circles
46−One of Hall's strengths is that it can not only interface with other Hall instances (Halls, if you will), but also external services. We define a single structure that can be used to specify both kinds of messaging targets.
49−++ partner (each circle passport) :< message target
50−++ circle {hos/ship nom/knot} :< native target
48+++ circle {hos/ship nom/term} :< native target
51−++ passport :> foreign target
52− $% {$twitter p/cord} :< twitter handle
56−A `partner` is either a `circle` or a `passport`. A `circle` is a native partner, essentially a named collection of messages created by and hosted on a ship's Hall, usually represented as `~ship-name/circle-name`.
51+A `circle` is essentially a named collection of messages created by and hosted on a ship's Hall, usually represented as `~ship-name/circle-name`. Most of Hall revolves around doing things with circles.
57−A `passport` is a non-native partner, such as a Twitter feed. The possibilities for passports are endless... but none of them are properly implemented yet. For the rest of this document we'll assume a `partner` is always a `circle`.
59### Messages
53### Messages
@@ -63,46 +57,36 @@ When we subscribe to a circle, the primary thing we're interested in is its mess
64++ speech :> content body
58++ speech :> content body
65 $% {$lin pat/? msg/cord} :< no/@ text line
59 $% {$lin pat/? msg/cord} :< no/@ text line
60+ {$url url/purf:eyre} :< parsed url
61+ {$exp exp/cord res/(list tank)} :< hoon line
66− {$ire tos/serial sep/speech} :< in-reply-to
62+ {$ire top/serial sep/speech} :< in reply to
67− {$url url/purf} :< parsed url
63+ {$fat tac/attache sep/speech} :< attachment
68− {$app app/term msg/cord} :< app message
64+ {$app app/term sep/speech} :< app message
69− {$ext nom/term dat/*} :< extended action
65+ {$inv inv/? cir/circle} :< inv/ban for circle
74−At the heart of every message lies a `speech` that describes the message body. There's a large number of different speech types, from simple text messages to parsed URLs, Hoon expressions and more. Thought the system strives to eventually accommodate all use cases, the `%ext` speech type provides extensibility for applications that feel their needs aren't covered.
69+At the heart of every message lies a `speech` that describes the message body. There's a large number of different speech types, from simple text messages to parsed URLs, Hoon expressions and more.
77−++ statement {wen/@da boq/bouquet sep/speech} :< when what body
78−++ bouquet (set flavor) :< complete aroma
79−++ flavor path :< content flavor
82−Message bodies are wrapped in a `statement` which specifies the timestamp and `flavor` of its content, the latter of which can in the future be used to filter out the kinds of content you personally do not wish to see.
85−++ audience (map partner (pair envelope delivery)) :< destination + state
72+++ audience (set circle) :< destinations
86−++ envelope {vis/? sen/(unit partner)} :< visible sender
73+++ serial @uvH :< unique identifier
87−++ delivery :> delivery state
74+++ thought :> inner message
88− $? $pending :< undelivered
75+ $: uid/serial :< unique identifier
89− $received :< delivered
76+ aud/audience :< destinations
90− $rejected :< undeliverable
77+ wen/@da :< timestamp
91− $released :< sent one-way
78+ sep/speech :< content
92− $accepted :< fully processed
96−When specifying a message's destination, an `audience` is used. It contains all the recipients of the message, as well as the delivery state for each of those recipients.
82+A `speech` is always accompanied by various bits of metadata. We include a unique identifier, a message timestamp and an `audience`, the set of all intended recipients of the message.
99−++ telegram {aut/ship tot/thought} :< who thought
85+++ telegram {aut/ship thought} :< whose message
100−++ thought {uid/serial aud/audience sam/statement} :< which whom this
86+++ envelope {num/@ud gam/telegram} :< outward message
101−++ serial @uvH :< unique identifier
104−The message and its destination get put into a `thought`, which also carries a universally unique identifier. This way, recipients can easily check whether they're receiving a new message or a potentially modified version of an existing one.
89+Finally, before sending the message over the wire, we add on the message's original author. In most cases, we also include a sequence number, the index of the message in the originating circle's list of messages. This can be a useful point of reference for clients.
105−Finally, all this gets put into a `telegram` which tags it with the message's author.
107### Participant metadata
91### Participant metadata
@@ -119,20 +103,21 @@ Messages aren't the only thing a subscription gets us. We're also kept up to dat
119 $talk :< typing
103 $talk :< typing
121++ human :> human identifier
105++ human :> human identifier
122− $: tru/(unit (trel cord (unit cord) cord)) :< true name
123− han/(unit cord) :< handle
106+ $: han/(unit cord) :< handle
107+ tru/(unit truename) :< true name
109+++ truename {fir/cord mid/(unit cord) las/cord} :< real-life name
127`status` is user-set metadata that describes, well, the status of users in a circle. This encompasses their `presence`, which shows their activity, and their `human` identity, which includes their display handle.
112`status` is user-set metadata that describes, well, the status of users in a circle. This encompasses their `presence`, which shows their activity, and their `human` identity, which includes their display handle.
128−For reasons we'll discover shortly, circles keep track of both their own `group` and those of the partners they're subscribed to. `crowd` encapsulates this.
113+For reasons we'll discover shortly, circles keep track of both their own `group` and those of the circles they're subscribed to. `crowd` encapsulates this.
130### Configurations
115### Configurations
133++ lobby {loc/config rem/(map circle config)} :< our & srcs configs
118++ lobby {loc/config rem/(map circle config)} :< our & srcs configs
134++ config :> circle config
119++ config :> circle config
135− $: src/(set partner) :< active sources
120+ $: src/(set circle) :< active sources
136 cap/cord :< description
121 cap/cord :< description
137 fit/filter :< message rules
122 fit/filter :< message rules
138 con/control :< restrictions
123 con/control :< restrictions
@@ -154,10 +139,10 @@ Lastly, there's a `control` structure that contains both a security mode and a l
156++ security :> security mode
141++ security :> security mode
157− $? $black :< channel, blacklist
142+ $? $channel :< blacklist
158− $white :< village, whitelist
143+ $village :< whitelist
159− $green :< journal, author list
144+ $journal :< pub r, whitelist w
160− $brown :< mailbox, our r, bl w
145+ $mailbox :< our r, blacklist w
@@ -172,13 +157,13 @@ To see how that all ties together, we're going to take a look at Hall's state.
174++ state :> hall state
159++ state :> hall state
175− $: stories/(map knot story) :< conversations
160+ $: stories/(map term story) :< conversations
176 :: ... ::
161 :: ... ::
178++ story :> wire content
163++ story :> wire content
179 $: grams/(list telegram) :< all messages
164 $: grams/(list telegram) :< all messages
180 locals/group :< local presence
165 locals/group :< local presence
181− remotes/(map partner group) :< remote presence
166+ remotes/(map circle group) :< remote presence
182 shape/config :< configuration
167 shape/config :< configuration
183 mirrors/(map circle config) :< remote config
168 mirrors/(map circle config) :< remote config
184 :: ... ::
169 :: ... ::
@@ -191,23 +176,27 @@ With the configuration described above in mind, we can try and imagine the thing
192### General use
177### General use
194−Upon initial startup, Hall creates a default story, a mailbox named `porch`. (This name is different for stars and galaxies: `floor` and `court` respectively.) This mailbox is the primary target for anyone and anything that wants to reach its owner. Applications can use it to send notifications and other information to the user (Hall itself does this as well), and users can use it to direct-message others.
179+Upon initial startup, Hall creates a default story, a mailbox named `inbox`. This mailbox is the primary target for anyone and anything that wants to reach its owner. Applications can use it to send notifications and other information to the user (Hall itself does this as well), and users can use it to send direct messages to each other.
196−Applications that use Hall are encouraged to use the default mailbox as the primary messaging hub. This way, users can easily switch between different applications without "losing" their subscriptions, message backlog, etc.
181+Applications that use Hall, especially clients, are encouraged to use the default mailbox as the primary messaging hub. This way, users can easily switch between different applications without "losing" their subscriptions, message backlog, etc.
198−As an example, Talk operates like this, serving as an interface for reading from and managing the user's mailbox. Local stories are subscribed to through the `porch`, which ends up containing all messages the user receives.
183+As an example, Talk operates like this, serving as an interface for reading from and managing the user's mailbox. Local stories are subscribed to through the `inbox`, which ends up containing all messages the user receives.
200### Federation
185### Federation
202Some places, like `urbit-meta`, will want to be easily accessible to everyone on the network, and actually support the load that comes with that. Both these desired can be met through federation.
187Some places, like `urbit-meta`, will want to be easily accessible to everyone on the network, and actually support the load that comes with that. Both these desired can be met through federation.
204In federation, stories and any changes to them trickle down from ~zod, to other galaxies, to their stars. Only changes to messages and presence can also move upstream, from stars, to galaxies, to ~zod (and then back down again).
189In federation, stories and any changes to them trickle down from ~zod, to other galaxies, to their stars. Only changes to messages and presence can also move upstream, from stars, to galaxies, to ~zod (and then back down again).
205−This way, all planets and comets will be able to subscribe to `/urbit-meta` and get all updates on the story, regardless of where on the network they originated.
190+This way, all planets and comets will be able to subscribe to `/urbit-meta` (that is, the `urbit-meta` circle on their parent ship) and get all updates on the story, regardless of where on the network they originated.
192+### Public membership
194+To aid in discoverability of circles, it is possible for users to make their participation in any given circle public. This data can then be used by things like profile widgets, or read out directly by other users.
208## Interfaces for applications
197## Interfaces for applications
210−Applications can interact with Hall in two complementary ways: they can tell it what actions to perform, and they can subscribe to its state changes.
199+Applications can interact with Hall in two complementary ways: they can tell it what actions to perform, and they can subscribe to its state and the changes made to it.
212### Interactions
201### Interactions
@@ -216,21 +205,23 @@ Hall can be commanded by poking it with `action`s.
217++ action :> user action
206++ action :> user action
218 $% :: circle configuration ::
207 $% :: circle configuration ::
219− {$create nom/knot des/cord sec/security} :< create circle
208+ {$create nom/term des/cord sec/security} :< create circle
220− {$delete nom/knot why/(unit cord)} :< delete + announce
209+ {$delete nom/term why/(unit cord)} :< delete + announce
221− {$depict nom/knot des/cord} :< change description
210+ {$depict nom/term des/cord} :< change description
222− {$filter nom/knot fit/filter} :< change message rules
211+ {$filter nom/term fit/filter} :< change message rules
223− {$permit nom/knot inv/? sis/(set ship)} :< invite/banish
212+ {$permit nom/term inv/? sis/(set ship)} :< invite/banish
224− {$source nom/knot sub/? src/(set partner)} :< un/sub to/from src
213+ {$source nom/term sub/? srs/(set source)} :< un/sub to/from src
225 :: messaging ::
214 :: messaging ::
226 {$convey tos/(list thought)} :< post exact
215 {$convey tos/(list thought)} :< post exact
227− {$phrase aud/(set partner) ses/(list speech)} :< post easy
216+ {$phrase aud/audience ses/(list speech)} :< post easy
228 :: personal metadata ::
217 :: personal metadata ::
229− {$notify nos/(set knot) pes/presence} :< our presence update
218+ {$notify aud/audience pes/(unit presence)} :< our presence update
230− {$naming nos/(set knot) man/human} :< our name update
219+ {$naming aud/audience man/human} :< our name update
231 :: changing shared ui ::
220 :: changing shared ui ::
232− {$human sip/ship man/human} :< new identity
233− {$glyph gyf/char pas/(set partner) bin/?} :< un/bind a glyph
221+ {$glyph gyf/char aud/audience bin/?} :< un/bind a glyph
222+ {$nick who/ship nic/cord} :< new identity
224+ {$public add/? cir/circle} :< show/hide membership
@@ -242,32 +233,38 @@ To send messages, two interfaces are available. `%convey` lets you specify all d
243"Shared UI" encompasses UI data that should be consistent across applications. For example, if the user sets a local nickname for an identity, they expect to see that nickname regardless of the application they're currently using. The same goes for glyph bindings, for easy audience targeting.
234"Shared UI" encompasses UI data that should be consistent across applications. For example, if the user sets a local nickname for an identity, they expect to see that nickname regardless of the application they're currently using. The same goes for glyph bindings, for easy audience targeting.
245−Sometimes, in response to a user action, Hall will respond with a `reaction`.
248−++ reaction :> user information
249− $: res/?($info $fail) :< result
251− why/(unit action) :< cause
255−These are used to inform the application (and thus the user) of any unexpected side effects or errors that occurred as a result of the action they issued.
257### Queries, prizes and rumors
236### Queries, prizes and rumors
259−To receive data from Hall, applications will have to query it. There are two paths that are useful for readers to query. Let's look at them and their results.
238+To receive data from Hall, applications will have to query it. There are two paths that are useful for clients to query. Let's look at them and their results.
262++ query :> query paths
241++ query :> query paths
263− $% {$reader $~} :< shared ui state
242+ $% {$client $~} :< shared ui state
264− {$circle nom/knot ran/range} :< story query
243+ $: $circle :> story query
244+ nom/naem :< circle name
245+ wat/(set circle-data) :< data to get
246+ ran/range :< query duration
265 :: ... ::
248 :: ... ::
267−++ range (unit {hed/place tal/(unit place)}) :< msg range, @ud/@da
250+++ circle-data :> kinds of circle data
268−++ place $%({$da @da} {$ud @ud}) :< point for range
251+ $? $grams :< messages
252+ $group-l :< local presence
253+ $group-r :< remote presences
254+ $config-l :< local config
255+ $config-r :< remote configs
257+++ range :> inclusive msg range
258+ %- unit :< ~ means everything
259+ $: hed/place :< start of range
260+ tal/(unit place) :< opt end of range
262+++ place :> range indicators
263+ $% {$da @da} :< date
264+ {$ud @ud} :< message number
269++ prize :> query result
266++ prize :> query result
270− $% $: $reader :< /reader
267+ $% $: $client :< /client
271 gys/(jug char (set partner)) :< glyph bindings
268 gys/(jug char (set partner)) :< glyph bindings
272 nis/(map ship cord) :< nicknames
269 nis/(map ship cord) :< nicknames
@@ -281,37 +278,38 @@ To receive data from Hall, applications will have to query it. There are two pat
284−To be clear, the paths for those queries are `/reader` and `/circle/[name]/[start]/[end]`, where `start` and `end` are optional and can be either a date or a message number.
281+To be clear, the paths for those queries are `/client` and `/circle/[name]/[data]/[start]/[end]`, where data is at least one `circle-data`, and `start` and `end` are optional and can be either a date or a message number.
285−`/reader` queries produce shared UI state. That is, glyph bindings and nicknames.
282+`/client` queries produce shared UI state. That is, glyph bindings and nicknames.
286`/circle` queries produce the entire public state of the requested story, including remotes.
283`/circle` queries produce the entire public state of the requested story, including remotes.
288Any changes to the results of these queries are communicated via the following `rumor`s. It's a fairly long list of potential changes,
285Any changes to the results of these queries are communicated via the following `rumor`s. It's a fairly long list of potential changes,
291++ rumor :< query result change
288++ rumor :< query result change
292− $% $: $reader :< /reader
289+ $% {$client rum/rumor-client} :< /client
294− $% {$glyph diff-glyph} ::
295− {$nick diff-nick} ::
298− {$circle dif/diff-story} :< /circle
290+ {$circle rum/rumor-story} :< /circle
299 :: ... ::
291 :: ... ::
293+++ rumor-client :< changed ui state
294+ $% {$glyph diff-glyph} :< un/bound glyph
295+ {$nick diff-nick} :< changed nickname
301−++ diff-glyph {bin/? gyf/char pas/(set partner)} :< un/bound glyph
297+++ diff-glyph {bin/? gyf/char aud/audience} :< un/bound glyph
302++ diff-nick {who/ship nic/cord} :< changed nickname
298++ diff-nick {who/ship nic/cord} :< changed nickname
303−++ diff-story ::
299+++ diff-story :> story change
304 $% {$new cof/config} :< new story
300 $% {$new cof/config} :< new story
305− {$grams gaz/(list telegram)} :< new/changed msgs
306 {$config cir/circle dif/diff-config} :< new/changed config
301 {$config cir/circle dif/diff-config} :< new/changed config
307− {$status pan/partner who/ship dif/diff-status} :< new/changed status
302+ {$status cir/circle who/ship dif/diff-status} :< new/changed status
308− {$follow sub/? pas/(set partner)} :< un/subscribe
309 {$remove $~} :< removed story
303 {$remove $~} :< removed story
310 :: ... ::
304 :: ... ::
306+++ rumor-story ::> story rumor
307+ $? diff-story ::< both in & outward
308+ $% {$gram nev/envelope} ::< new/changed msgs
312++ diff-config :> config change
310++ diff-config :> config change
313 $% {$full cof/config} :< set w/o side-effects
311 $% {$full cof/config} :< set w/o side-effects
314− {$source add/? pas/(set partner)} :< add/rem sources
312+ {$source add/? src/source} :< add/rem sources
315 {$caption cap/cord} :< changed description
313 {$caption cap/cord} :< changed description
316 {$filter fit/filter} :< changed filter
314 {$filter fit/filter} :< changed filter
317 {$secure sec/security} :< changed security
315 {$secure sec/security} :< changed security
@@ -322,16 +320,16 @@ Any changes to the results of these queries are communicated via the following `
322 $% {$full sat/status} :< fully changed status
320 $% {$full sat/status} :< fully changed status
323 {$presence pec/presence} :< changed presence
321 {$presence pec/presence} :< changed presence
324 {$human dif/diff-human} :< changed name
322 {$human dif/diff-human} :< changed name
325− {$remove $~} :< removed config
323+ {$remove $~} :< removed status
327++ diff-human :> name change
325++ diff-human :> name change
328 $% {$full man/human} :< fully changed name
326 $% {$full man/human} :< fully changed name
329− {$true tru/(unit (trel cord (unit cord) cord))} :< changed true name
330 {$handle han/(unit cord)} :< changed handle
327 {$handle han/(unit cord)} :< changed handle
328+ {$true tru/(unit truename)} :< changed true name
334−These are, as enforced by Gall, the changes as they happen. This makes it possible for very minimal Hall readers to be implemented that only show a stream of changes, rather than keeping state themselves.
332+These are, as enforced by Gall, the changes as they happen. This makes it possible for very minimal Hall clients to be implemented that only display a stream of changes, rather than keeping state themselves.
337## Communication between Halls
335## Communication between Halls
@@ -345,7 +343,7 @@ To request changes to a story, Halls can send `command`s.
346++ command :> effect on story
344++ command :> effect on story
347 $% {$publish tos/(list thought)} :< deliver
345 $% {$publish tos/(list thought)} :< deliver
348− {$present nos/(set knot) dif/diff-status} :< status update
346+ {$present nos/(set term) dif/diff-status} :< status update
349 :: ... ::
347 :: ... ::
@@ -361,14 +359,14 @@ Halls can query other halls. Here's the peer move we send when we open a query o
362:* ost.bol :< bone
360:* ost.bol :< bone
363 %peer :< move type
361 %peer :< move type
364− /circle/[our-circle]/[host]/[their-circle] :< rumor path
362+ /[our-circle]/[host]/[query-path] :< rumor path
365 [host %hall] :< query target
363 [host %hall] :< query target
366− /circle/[their-circle]/[start]/[end] :< query path
364+ /circle/[their-circle]/[data]/[start]/[end] :< query path
370Again, the rumor path is what our Hall uses to identify what query a received message originates from. Our circle is specified so that we know what story is interested in the changes we get.
368Again, the rumor path is what our Hall uses to identify what query a received message originates from. Our circle is specified so that we know what story is interested in the changes we get.
371−The query path is slightly more interesting. Of course it specifies the name of their story we want to subscribe our story to, but also a "start" and "end". These can (optionally) be used to specify the range of messages we want to get from our query. Once we're out of that range, we stop receiving updates.
369+The query path is slightly more interesting. Of course it specifies the name of their story we want to subscribe our story to, but also a "start" and "end". These can (optionally) be used to specify the range of messages we want to get from our query. Once that range has passed, we stop receiving updates.
373### Federation
371### Federation
@@ -381,23 +379,27 @@ Along the way so far, we've skipped some parts of structures. Most of these rela
381 :: ... ::
379 :: ... ::
383++ prize :> query result
381++ prize :> query result
384− $% {$burden sos/(map knot burden)} :< /burden
382+ $% {$burden sos/(map term burden)} :< /burden
385 :: ... ::
383 :: ... ::
387++ rumor :< query result change
385++ rumor :< query result change
388− $% {$burden nom/knot dif/diff-story} :< /burden
386+ $% {$burden nom/term rum/rumor-story} :< /burden
389 :: ... ::
387 :: ... ::
391++ diff-story ::
389++ diff-story ::
392 $% {$bear bur/burden} :< new inherited story
390 $% {$bear bur/burden} :< new inherited story
393− {$burden bur/?} :< burden flag
394 :: ... ::
391 :: ... ::
393+++ burden :> full story state
394+ $: gaz/(list telegram) :< all messages
395+ cos/lobby :< loc & rem configs
396+ pes/crowd :< loc & rem presences
398We briefly touched upon how federation works on the higher level. On the lower, this is how things go down.
400We briefly touched upon how federation works on the higher level. On the lower, this is how things go down.
400−1. When Hall boots on a star or galaxy, it starts querying its parent's (~zod for galaxies) `/burden` path.
402+1. When Hall boots on a star or galaxy, it starts querying its parent's `/burden` path. (Galaxies query ~zod.)
4012. Upon receiving that query, the parent sends a `%burden` prize containing all state of its channels (fully public circles) to the child. It also subscribes to `/report` on that child.
4032. Upon receiving that query, the parent sends a `%burden` prize containing all state of its channels (fully public circles) to the child. It also subscribes to `/report` on that child.
4023. When a new story gets created on the parent, its children get a `%burden` rumor with a `%bear` story diff, and they create a local copy of that channel.
4043. When a new story gets created on the parent, its children get a `%burden` rumor with a `%bear` story diff, and they create a local copy of that channel.
4034. When something about a parent's story changes, a `%burden` rumor is sent to all its children (because they're querying `/burden`). The children apply this change to their local version of the story.
4054. When something about a parent's story changes, a `%burden` rumor is sent to all its children (because they're querying `/burden`). The children apply this change to their local version of the story.
@@ -423,7 +425,7 @@ For brevity, utility arms that aren't a direct and important part of the flow ha
424(You will find that the origins still use old Gall arms, with some glue code in between. At the time of writing, new Gall has not yet been implemented, so this will have to do.)
426(You will find that the origins still use old Gall arms, with some glue code in between. At the time of writing, new Gall has not yet been implemented, so this will have to do.)
426−We will generally only display the delta generation parts of the flow. Delta application is usually implemented simply enough to deduce what it does from looking at the label.
428+We will only display the delta generation parts of the flow. Delta application is usually implemented simply enough to deduce what it does from looking at the label.
428### Subscriptions
430### Subscriptions
@@ -485,9 +487,9 @@ Hall is neither complete nor perfect. There are features that need to be impleme
486### Features and functionality
488### Features and functionality
488−To turn talk into a [sustainable social platform](https://urbit.org/fora/posts/~2017.4.26..18.00.25..b93c~/), it needs a number of things.
490+To turn Talk into a [sustainable social platform](https://urbit.org/fora/posts/~2017.4.26..18.00.25..b93c~/), it needs a number of things.
490−Primarily, discoverability of circles. A possible solution for realizing this is making it possible for users to add friends, which would have their Hall subscribe to a list of circles the added friends are in. Of course, one will be able to set joined circles as "private" to keep them from being visible to others.
492+Primarily, discoverability of circles. A possible solution for realizing this is making it possible for users to add friends, which would have their Hall subscribe to a list of circles the added friends are in. The existing public membership functionality can be leveraged for this.
492Eventually, content self-moderation might need to be implemented. Users would flag their content if it is potentially offensive. Others would easily be able to filter out content that might offend them.
494Eventually, content self-moderation might need to be implemented. Users would flag their content if it is potentially offensive. Others would easily be able to filter out content that might offend them.
493This functionality brings its own large sets of challenges that need to be tackled.
495This functionality brings its own large sets of challenges that need to be tackled.
@@ -500,7 +502,6 @@ Other changes that might have a fair impact on the functioning of Hall are un/re
500Smaller functionality that still needs to be implemented includes:
502Smaller functionality that still needs to be implemented includes:
501* Extended permissions management. Being able to black-/whitelist entire ship classes.
503* Extended permissions management. Being able to black-/whitelist entire ship classes.
502* Improved presence functionality. Actually using the presence system, and sending "typing", "idle", etc. statuses.
504* Improved presence functionality. Actually using the presence system, and sending "typing", "idle", etc. statuses.
503−* Flexible on-subscribe scrollback. Some cases may want more than just a day's worth.
506And of course there's a lot Talk, the client, can improve on as well.
507And of course there's a lot Talk, the client, can improve on as well.
@@ -509,7 +510,7 @@ And of course there's a lot Talk, the client, can improve on as well.
509## Further reading
510## Further reading
511To gain a more thorough understanding of Hall's inner workings, take a look at its source code. It comes with inline documentation.
512To gain a more thorough understanding of Hall's inner workings, take a look at its source code. It comes with inline documentation.
512−[link]
513+[On Github.](https://github.com/urbit/arvo/blob/master/app/hall.hoon)
514−To see an expansive example of an application that uses Hall, take a look at the code of Talk. It, too, comes with inline documentation.
515+To see an expansive example of a Hall client, take a look at the code of Talk. It, too, comes with inline documentation.
515−[link]
516+[On Github.](https://github.com/urbit/arvo/blob/master/app/talk.hoon)