git.iko.soy/urbit.org
on master help sign in
Merge branch 'master' of https://github.com/urbit/urbit.org
6f7cab0Mike Osborne
content/blog/a-topiary.mdnew file+49
compare with master
unifiedsplit
@@ -0,0 +1,49 @@
1++++
2+title = "A Topiary: Hypertext and Urbit"
3+date = 2021-06-14
4+description = "A brief history of hypertext and Urbit networking"
5+[extra]
6+author = "Reid Scoggin"
7+ship = "~sitful-hatred"
8+image = "https://media.urbit.org/site/posts/essays/treebranches.jpeg"
9++++
10+
11+![](https://media.urbit.org/site/posts/essays/treebranches.jpeg)
12+
13+
14+> Under the trees of England I meditated on this lost and perhaps mythical labyrinth. I imagined it untouched and perfect on the secret summit of some mountain; I imagined it drowned under rice paddies or beneath the sea; I imagined it infinite, made not only of eight-sided pavilions and of twisting paths but also of rivers, provinces and kingdoms... I thought of a maze of mazes, of a sinuous, ever growing maze which would take in both past and future and would somehow involve the stars.
15+
16+
17+-- *The Garden of Forking Paths*, Jorge Luis Borges
18+
19+
20+The pre-technological world was already [networked](https://en.wikipedia.org/wiki/Indra%27s_net). No material object and no idea has ever stood alone—"no man is an island". Language itself is a network of associations shared between a group of people. The question of technology is: how do we bring our web of associations into the realm of computers? The legacy internet has focused on social networks almost exclusively—our mammalian brains readily took to this, we all love to [signal](https://conversationswithtyler.com/episodes/robin-hanson/). But before “social media” there was something called hypertext: a seemingly modest way to connect documents shared between computers.
21+
22+A footnote in a book used to require a library, locating the referenced book, and finding the cited page (which might have footnotes itself)! Hypertext allows one to traverse a network quickly and easily with just mouse clicks, making information accessible to those without the time and resources to hunt down physical artifacts. Urbit’s “%graph-store” is not the same as hypertext but it does bear some familial resemblances. Fundamentally, %graph-store is a data structure that can accommodate disparate data types within a single edifice. It is based on [graph databases](https://en.wikipedia.org/wiki/Graph_database) and recent implementations such as [GraphQL](https://graphql.org/). To understand this data structure it is worth diving into the origins of hypertext—the original linked network.
23+
24+The story of hypertext begins at the end of WWII with an article in *The Atlantic* that proposed to extend the human mind via machine. Vannevar Bush had seen first-hand the explosion of electronics manufacturing and scientific knowledge, recognizing the great peril and opportunity of such a revolution. His [description](https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/) of the Memex presaged the technological world of today, envisioning a personal device that would allow the user to draw upon a vast library of information, and link documents together arbitrarily—what he called "associative indexing"—a deliberate recreation of how the mind connects thoughts.
25+
26+
27+The 1960s saw the first implementations of these ideas. Ted Nelson's [writing](https://archive.org/details/SelectedPapers1977/page/n15/mode/2up) around *Project Xanadu* elaborated this linking between documents into what Nelson called *hypertext*. Nelson imagined "a text arranged in a graph structure", centered around a corpus arranged in nonlinear sequence, manipulable by author or audience. The concept was first demonstrated in 1968, at Douglas Engelbart's 'Mother of all Demos', where a vision of computers as a collaborative social environment was revealed to the world. "[The Journal](https://www.dougengelbart.org/content/view/137/#7)", presented alongside other revolutionary demos, exhibited collaboratively edited documents with hyperlinked connections. Any time-travellers in the audience would have immediately recognized the first webpage. From here, the idea of a linked network of documents would be developed through successive phases of computing, from the mainframe to the PC.
28+
29+
30+Experimentation with these ideas continued through the 1970s and 80s. A team directed by Andy Lippman at MIT extended the concept to threaded visual hypermedia with the *Aspen Movie Map*, a user-directed virtual tour of Aspen, Colorado. Hypertext and hypermedia gained a mass audience for the first time with HyperCard, a program that shipped with Mac computers. Users were able to collect or create '[stacks](https://archive.org/details/hypercardstacks
31+)' of interlinked cards; a personal body of text, art, and knowledge could be accrued and modified, or shared with others—though not yet with native networking capabilities.
32+
33+
34+With the World Wide Web, hypertext achieved escape velocity. Initially a one-man [project](http://info.cern.ch/hypertext/WWW/TheProject.html), the world wide web was similar to Bush’s vision of the Memex—a way to share, index, and connect information between individuals and groups. The web succeeded by utilizing the physical infrastructure already available: PCs with graphical interfaces, DNS, and the internet. Critically, its method of transmitting and traversing texts was a standardized protocol, allowing a free body of information to assemble atop the new infrastructure by anyone willing to learn the tools. A new frontier was cleared and cultivated with open standards, but it would gradually face enclosure.
35+
36+
37+In the following decade, after the first wave of social networking sites had crested but before phones became the primary web clients, Twitter was launched. Originally an awkward bridge between SMS and the web, its design eventually coalesced around static identity, posts with chronological sorting, and interlinked post threads. These simple primitives spawned a vast corpus of information, a graph-of-graphs intertwined and overlapped, mapping an entire platonic world. Twitter is fundamentally constrained by its very nature: it is the walled garden of an advertising company. The financial incentives of the server operators demanded seizure of the commons and the replacement of standardized protocols with proprietary databases.
38+
39+
40+As the first networked services withered, a new critique was implicitly articulated in the construction of a [new kind of abstract machine](https://moronlab.blogspot.com/2010/01/urbit-functional-programming-from.html). Urbit learned from the past: tightly defined protocols, baked-in cryptography, and decentralization were key. If power over the network was determined by those who ran the servers, then we would run the servers ourselves.
41+
42+
43+Urbit is not fundamentally a hypertext system; it is a new kind of computer, designed to participate in a peer-to-peer network that rejects the client-server model. All Urbit software takes its networking model for granted, it is not an ad-hoc layering of mismatched abstractions. Fundamental design decisions determine the trajectory of the future.
44+
45+
46+Early [implementations](https://en.wikipedia.org/wiki/Neo4j) of graph databases and projects like [RDF](https://en.wikipedia.org/wiki/Resource_Description_Framework) hit on the same core idea: linked data needs its own data structure. In 2020 Urbit OS adopted an application called %graph-store that made use of a new, native [data structure](https://docs.google.com/document/d/1-Gwfg442kV3cdfG7NnWPEf2TMa3uLUTAKkZD70ALZkE/edit) which would act as a database service for social applications. Chats, long-form text, and other types of data produced in the course of social computing now share the same tent, a single structure extensible to new types of content. Each item added to it is a node in a personal graph—a tree that grows branches as your computer communicates. These nodes can be linked arbitrarily to other graphs—Urbit's global immutable namespace grants both permanence and ownership and allows the graph’s branches to intertwine with others. Graphs can accommodate a variety of content, from simple text, to code and media yet to be conceived. You own your graph, and it is a record of your digital journey with others.
47+
48+
49+Personal hypertext graphs are leaving behind proprietary platforms and gaining independence. Graphs until now have been used as tools of surveillance and marketing, but they are being reclaimed and sewn back into the network, each bound to the cryptographic identity of an individual, permanent computer. Where the map of your life was once splintered across a thousand systems and held in the custody of strangers, it is now possessed only by you and shared only as you see fit. On Urbit, an infinite forest of digital lives can take root, nesting their boughs and stalks.
content/blog/first-contract.mdnew file+299
@@ -0,0 +1,299 @@
1++++
2+title = "Azimuth’s First Contract Upgrade"
3+date = 2021-06-05
4+description = "Galactic Senate makes first concrete action"
5+[extra]
6+author = "Jonathan Paprocki and Mark"
7+ship = "~datnut-pollen and ~palfun-foslup"
8+image = "https://media.urbit.org/site/posts/essays/land3.jpg"
9++++
10+
11+<br>
12+
13+![milestone](https://media.urbit.org/site/posts/essays/land3.jpg)
14+
15+<br>
16+
17+Recently, the [first upgrade](https://github.com/urbit/azimuth/pull/35) to the
18+[Azimuth](@/docs/glossary/azimuth.md) smart contracts which make up Urbit ID was
19+put up to an [upgrade proposal vote](@/docs/glossary/upgrade.md) by the
20+[Galactic Senate](@/docs/glossary/senate.md). This vote is still open and will
21+last for 30 days (June 20th) or until an absolute majority is reached. We’d like
22+to take this opportunity to discuss two things. [First](#changelist), what the
23+proposed changes are, and [second](#senate), a review of how Urbit governance
24+works and where we’re at with respect to the decentralization process.
25+
26+Before we dive into what the proposed changes are, let’s review what the Senate
27+is actually capable of changing. Urbit ID is really two sets of smart contracts:
28+Azimuth and [Ecliptic](@/docs/glossary/ecliptic.md). Azimuth is the data of the
29+public key infrastructure - roughly, this is the list of
30+[ships](@/docs/glossary/ship.md) and which Ethereum addresses own them, along
31+with other data such as networking keys and sponsorship status. The Senate has
32+no ability to touch this data directly. This is in direct contrast to all
33+existing centralized services, where your account is always at risk of being
34+taken away from you. What the Senate can change is Ecliptic, which is the
35+“business logic” that decides how you can interact with the data in Azimuth.
36+These are mechanisms such as what powers various
37+[proxies](@/docs/glossary/proxies.md) have, how stars/planets are released over
38+time, and how sponsorship works. Put another way, the data and database format
39+must remain the same, but the rules by which we interact with it may change
40+according to the governance rules we [detail below](#senate).
41+
42+## Changelist {#changelist}
43+
44+The currently open vote to Ecliptic contains the following changes:
45+
46+- Fixed ERC721 compatibility
47+- Self-modifying proxies
48+- Upgraded Claims contract
49+
50+### Fixed ERC721 compatibility
51+
52+The contract definition of the Ecliptic includes various functions and events
53+that make it conform to the ERC721 (non-fungible token) standard. However, two
54+events have [ever so slightly
55+non-confirming](https://github.com/urbit/azimuth/issues/8) descriptions. This
56+causes Ethereum explorers like Etherscan to incorrectly recognize Azimuth as
57+ERC20 (fungible token), rather than ERC721.
58+
59+The proposed change simply modifies the event descriptions to accurately match
60+the ERC721 definition. This does not affect any functionality within the
61+contract itself.
62+
63+### Self-modifying proxies
64+
65+Owners of Azimuth assets are allowed to configure "proxy addresses" for those
66+assets: Ethereum addresses allowed to act "as" the owner, but only for a subset
67+of operations. For example, setting the management proxy will let you change
68+your networking keys and sponsor using that address, just like your ownership
69+address can. This is useful for keeping the ownership keys in very cold storage,
70+while still letting you perform lower-value operations.
71+
72+Currently, only the ownership address is allowed to change proxy addresses.
73+Fairly early on after Azimuth's deployment, we realized it might be nice for
74+proxies to be able to change themselves.
75+
76+This means that, in addition to being able to configure networking keys and
77+sponsorship, your management proxy would be able to assign a new management
78+proxy. This would allow you, or a trusted third party holding your management proxy,
79+to rotate your proxy keys without needing to take your ownership keys out of cold
80+storage.
81+
82+### Upgraded Claims contract
83+
84+[The Claims
85+contract](https://github.com/urbit/azimuth/blob/master/contracts/Claims.sol)
86+lets asset managers associate various attestations with their identity. For
87+example, an Ethereum address to send donations to, or proving ownership of a
88+Twitter account.
89+
90+For ease of use by off-chain tools and services, the contract emits events
91+(notifications) whenever any claims are updated. However, the current version of
92+the contract has a bug where it does not emit events when all claims are removed
93+at once (clearClaims()). This "gap" in the event stream makes it much more
94+difficult to write off-chain tools around this contract. Considering Claims has
95+seen [practically no
96+use](https://etherscan.io/address/0xe7e7f69b34d7d9bd8d61fb22c33b22708947971a#events)
97+since it was first deployed, it should not be a problem to simply start over
98+fresh with a new contract that contains [the
99+fix](https://github.com/urbit/azimuth/pull/32) for the described bug.
100+
101+The reason we must do an Ecliptic upgrade to switch to a new Claims contract, is
102+that it is tied in with the logic for transferring an asset. If the asset is
103+flagged for "reset" (common when transferring to/from someone other than
104+yourself), its configured proxies, networking keys and claims are cleared during
105+transfer. As such, the Ecliptic will need to know about the address of the new
106+Claims contract.
107+
108+## Urbit Governance {#senate}
109+
110+![geology](https://media.urbit.org/site/posts/essays/b1.jpg)
111+
112+The ultimate goal of Urbit is to become a digital republic manifested as a peer
113+to peer network owned and controlled by its users. The goal of Tlon, then, is to
114+become a company which builds products for Urbit rather than being the primary
115+driving force behind its development. We’d like to take this opportunity to
116+spell out our perspective on where we’re at in that process. We’ve already
117+written a good deal about Urbit governance in the past on this blog, so we avoid
118+rehashing too much, but the first contract upgrade is an apt time for a routine
119+checkup. Here are some previous posts that are relevant, but please note that
120+some of them are several years old and as such may not accurately reflect our
121+current position, but still serve as useful historical markers. We hope to
122+revisit and refresh these documents soon.
123+
124+- [2016.5.16 - Interim
125+Constitution](@/blog/interim-constitution.md)
126+- [2016.5.16 - The
127+Urbit Address Space](@/blog/the-urbit-address-space.md)
128+- [2016.6.24 - The DAO as a Lesson in Decentralized
129+Governance](@/blog/the-dao-as-a-lesson-in-decentralized-governance.md)
130+- [2019.1.11 - Governance of
131+urbit.org](@/blog/governance-of-urbit.md)
132+
133+### Galactic Senate
134+
135+The Galactic Senate is composed of all [galaxy](@/docs/glossary/galaxy.md)
136+holders, which at present consists of more than 100 individuals and a few
137+organizations, including Tlon and the Urbit.org Foundation. Using the Azimuth
138+voting contract, the Senate can present and vote on two kinds of proposals:
139+[document proposals](@/docs/glossary/docvote.md) and [upgrade
140+proposals](@/docs/glossary/upgrade.md). Thus far, all matters which the Senate
141+has voted on have been document proposals. The [most recent
142+vote](https://github.com/urbit/azimuth/pull/34) declared the Urbit network as
143+(i) being secure (as confirmed by a [third party
144+audit](@/blog/security-audit.md)) and (ii) having reached continuity (as in, no
145+further [network breaches](@/docs/glossary/breach.md) are expected). Previous votes
146+were to declare that [Azimuth is live](https://github.com/urbit/azimuth/pull/25)
147+and that [Arvo is stable](https://github.com/urbit/azimuth/pull/24).
148+
149+### Address space distribution
150+
151+Perhaps the most informative measure of how decentralized Urbit is in terms of
152+how many independent parties hold address space. By the very nature of Urbit, it
153+is impossible to know this with great accuracy (a common feature of
154+decentralized projects). However, the movement of galaxies is closely watched
155+and thus we have a fairly good idea of how distributed they are.
156+
157+In the beginning, Urbit’s creator Curtis Yarvin was in possession of the entire
158+address space - all 256 galaxies, and everything underneath it. A network of one
159+is no network at all, and so over the last decade Urbit’s development has been
160+primarily driven by selling or giving away these galaxies. On [June 1,
161+2016](@/blog/the-urbit-address-space.md), the allocation was:
162+
163+> 95, to the Tlon Corporation. 50, to urbit.org, the future community
164+> foundation. 40, to Tlon employees and their family members (24 to Curtis, who
165+> started in 2002; 16 to everyone else, who started in 2014). 34, to outside
166+> investors in Tlon. 37, to 33 other individuals, who donated to the project,
167+> contributed code or services, won a contest, or were just in the right place
168+> at the right time.
169+
170+In the period since then leading up to the present, Tlon has sold a number of
171+its galaxies to fund development, and others have changed hands, to the point
172+that Tlon and urbit.org no longer possess a majority share of galaxies. In
173+January 2019, [Curtis gave all of his galaxies](@/blog/a-founders-farewell.md) to
174+Tlon when he left the project. In August 2020 we shared an update on the [known
175+distribution of address space](@/blog/value-of-address-space-pt3.md), where
176+Curtis’ galaxies are marked as Tlon’s “naked galaxies”. Since then, Tlon
177+disbursed its naked galaxies among the employees that wanted one who did not
178+already possess one, thus removing Tlon and urbit.org’s controlling share of the
179+Senate. Galaxies held by current and former Tlon employees are entirely
180+independent of Tlon Corporation—they may do with them, and vote with them, as
181+they please. `~ravmel-ropdyl` plans to give more color to this decision in the
182+near future.
183+
184+Distribution of stars is much more difficult to know. There is an active market
185+for stars on [OpenSea](https://opensea.io/collection/urbit-id), so we know that
186+they are changing hands frequently, but checking the number of distinct Ethereum
187+addresses that hold stars does not tell you very much information since there
188+are many legitimate reasons one person might hold each of their stars at
189+different addresses.
190+
191+### Software and smart contracts
192+
193+As was written in [The DAO as a Lesson in Decentralized
194+Governance](https://urbit.org/blog/the-dao-as-a-lesson-in-decentralized-governance/),
195+we are keenly aware of the threat of _decentralization theater_. Urbit has
196+undergone steady progress towards decentralization, and with the developments we
197+outline below, it’s never been more clear that the project is beginning to leave
198+the cradle of Tlon. It’s also important to note that decentralization of a
199+project is always a procession away from an initial centralized state⁠—you cannot
200+go from A to Z without first traversing every letter in between. While Urbit was
201+centralized during its earliest stages, the journey towards a network owned and
202+controlled by the users is now well underway.
203+
204+In the past, nearly all Urbit software was written by Tlon. While Tlon is still the only corporation actively updating Urbit’s MIT-licensed open source software, namely [Vere](@/docs/glossary/vere.md) (the runtime), and [Arvo](@/docs/glossary/arvo.md) (the kernel), unaffiliated individuals have been making enormous contributions to Urbit over the past couple of years via the [grants program](https://grants.urbit.org/history). Recent examples include the [Bitcoin node and wallet integration](https://github.com/urbit/urbit/pull/4940), [WebRTC integration](https://grants.urbit.org/proposals/21131866-webrtc-gall-agent-and-external-app), [Port, an Urbit installer and ship manager](https://github.com/arthyn/port), and [`|fuse`, an important primitive for 3rd party software distribution](https://github.com/urbit/urbit/pull/4820).
205+
206+The only real power Tlon holds over Urbit is the ability to push [OTA
207+updates](@/docs/glossary/ota-updates.md) via `~zod`, and suggest that people
208+download our binaries. To the best of our knowledge, all extant galaxies
209+retrieve their OTA updates from `~zod`, who forward it to their stars, who
210+forward it to their planets. This software distribution route is merely a
211+convenient default setting. Ships initially retrieve OTA updates from their
212+sponsor, but they have full authority to retrieve updates from whoever they want
213+with the `|ota` command, or even to only install software updates by hand if
214+they so choose.
215+
216+In the future, one can easily imagine many organizations shipping their own
217+distributions of Urbit from their own urbit nodes, somewhat analogously to the
218+large number of Linux distributions which exist today. There is nothing we can
219+do to stop a group from forking Urbit, declaring `~sampel-palnet` the new `~zod`
220+(both for updates and for sponsorship purposes), and retrieving all OTA updates
221+via that route and building their own binaries. This is all by design, and we
222+wouldn’t want it any other way.
223+
224+The use of the Azimuth smart contracts is also somewhat optional. By changing a
225+few lines of code to point their ships at another set of PKI smart contracts,
226+they could rid themselves of hierarchical peer discovery entirely and make use
227+of some other routing strategy such as [Kademlia based DHT
228+routing](https://en.wikipedia.org/wiki/Kademlia). This would likely give rise to
229+an entirely separate network. The fact that the network is fully capable of such
230+a schism helps keep the Senate honest and accountable to the users. If they ever
231+were to vote on a contract modification that greatly angered or upset a portion
232+of the user base, they would be inviting such a schism and be entirely deserving
233+of it. In that sense, the power to control the network is already held by the
234+users, they just have not yet had a reason to make use of it.
235+
236+### Legitimacy
237+
238+The only way by which Tlon and the Senate hold any power is via legitimacy.
239+Vitalik Buterin recently wrote a [very informative
240+article](https://vitalik.ca/general/2021/03/23/legitimacy.html) on the role of
241+legitimacy in decentralized governance, and I do not know of a better source to
242+understand how Tlon and the Senate are kept in check by the users. Besides the
243+DAO split resulting in Ethereum and Ethereum Classic mentioned in the article,
244+perhaps the most prominent example of the power users have over a decentralized
245+network is the saga of [Steem and Justin
246+Sun](https://www.coindesk.com/justin-sun-bought-steemit-steem-moved-to-limit-his-power).
247+The short version of the story is that Justin Sun bought a controlling share of
248+the Steem blockchain and attempted to exert control over it, and the users
249+banded together to fork the blockchain into one called Hive, which was identical
250+to Steem except with Sun’s token balance set to zero. An analogous outcome for
251+Urbit would be that the Senate makes sweeping changes to the PKI and invites a
252+schism like that outlined above.
253+
254+For these reasons, there are strong disincentives for any one organization or
255+individual to acquire too many galaxies. The more galaxies one party possesses,
256+the fewer there are with strong incentives to stimulate efforts to build on the
257+network, reducing the value of holding that space, and the greater the risk that
258+the users will perceive this as a power grab by a party without their interests
259+in mind. This is in contrast to real-life republics, where there is little risk
260+for one party to accumulate as much power as they can manage since the cost to
261+the citizens to overthrow that power is enormous. Thus, only especially
262+egregious displays of power ever result in rebellion. Within the Urbit republic,
263+users need only to change the code they run to leave the Senate powerless, and
264+so the threat of rebellion is much more real. We estimate that within a digital
265+republic like Urbit, the centrifugal forces outweigh the centripetal forces, and
266+that the outcome of this is more stable than the reverse.
267+
268+### Why have governance at all?
269+
270+An important question the reader may still have lingering is: why does Urbit
271+need governance at all? The short answer is: (i) there will always be necessary
272+protocol upgrades that cannot be foreseen, and (ii) a total lack of governance
273+inevitably gives rise to a shadow government with undefined powers that is
274+almost impossible to hold accountable.
275+
276+With (ii), we see this to be the case on many early blockchain projects where
277+power is shared by the developers and the miners, but what each is capable of
278+doing has never been codified, and thus users of the blockchain can never have a
279+great deal of certainty of what changes might occur in the future. This doesn’t
280+guarantee a bad outcome, but it does create more wariness for individuals to
281+contribute to a project when they cannot know whether they really have a say in
282+its direction. Recognizing this issue, many newer blockchain and
283+blockchain-adjacent projects have built-in governance mechanisms that lay out
284+exactly what an individual can expect should they join and contribute to that
285+network.
286+
287+As for (i), with Urbit being a wholly new kind of network, it would take some
288+incredible luck and crystal ball gazing to get the PKI exactly right on the very
289+first try without ever needing another modification. Thus, some mechanism was
290+needed to guarantee that the PKI’s logic could be altered. Leaving control of
291+Azimuth in the hands of Tlon would have just granted Tlon dictatorial power and
292+a future that becomes more uncertain the further one gazes. There’s certainly
293+room to argue that the Galactic Senate is not a perfect system, but our interim
294+constitution did outline potential roles for stars and planets to play in
295+governance in the future, so there is ample opportunity for the system to evolve
296+in response to the will of the users. As always, it is important to keep in mind
297+the unfinished nature of the Urbit of today and the still moldable clay of the
298+Urbit of tomorrow⁠—nothing yet is set in stone.
299+
content/docs+1−1

Submodule changed.

content/events/2021-05-27-town-hall.md+1−1
@@ -2,7 +2,7 @@
2title = "Town Hall"
2title = "Town Hall"
3date = 2021-05-27
3date = 2021-05-27
4[extra]
4[extra]
5−pinned = true
5+pinned = false
6host = "Josh Lehman (~wolref-podlex)"
6host = "Josh Lehman (~wolref-podlex)"
7time = "12:00 - 15:30 PDT"
7time = "12:00 - 15:30 PDT"
8location = "Online Event"
8location = "Online Event"
content/events/2021-06-17-developer-workshop-bitcoin-lightning.mdnew file+22
@@ -0,0 +1,22 @@
1++++
2+
3+title = "Developer Call: Programming Bitcoin on Urbit Workshop"
4+date = 2021-06-17
5+[extra]
6+pinned = false
7+host = "Josh Lehman (~wolref-podlex)"
8+guests = "Tim (~timluc-miptev)"
9+time = "9:00 PDT"
10+location = "Online Event"
11+image = ""
12+registration_url = "https://www.meetup.com/urbit-sf/events/278758314/"
13+description = "Programming Bitcoin on Urbit"
14+youtube = "ltKz1MmluEY"
15+
16++++
17+
18+Programming Bitcoin is fun, particularly on Urbit, but the devil is in the details. Tim (~timluc-miptev) will impart the implicit knowledge he gained working with Bitcoin in the course of his projects, and give an open workshop on what you need to know, either to satisfy your curiosity or to jump in and help. Tim will give a structured presentation on low-level Bitcoin fundamentals, intended to make it easy to use Bitcoin resources for further study.
19+
20+Tim is the technical director at the Urbit Foundation, and wrote the backend for the Urbit Bitcoin wallet. He is currently managing `volt`, a project to integrate a Lightning client into Urbit. This workshop will be interactive &mdash; Tim will take questions throughout, and will conduct another session later if material remains.
21+
22+As always, there will be an informal call afterwards to hang out. We will also open a Bitcoin development channel on Urbit specifically to handle follow-ups from this and for those who can't make it live.
content/grants/apprenticeships/ua-3rd-party-software-distribution.mdnew file+50
@@ -0,0 +1,50 @@
1++++
2+title = "Apprenticeship: 3rd Party Software Distribution"
3+date = 2021-02-01
4+[taxonomies]
5+grant_type = ["apprenticeships"]
6+grant_category = ["App Dev: Core"]
7+[extra]
8+image = ""
9+description = "3rd party software distribution infrastructure"
10+reward = 5
11+mentor = "~wolref-podlex"
12+assignee = "~sovmep-ripsum"
13+completed = false
14+work_request_link = "https://airtable.com/shr4qt9t9kz7RaOIa?prefill_Grant+ID=B0025"
15++++
16+
17+## Scope
18+
19+Ultimate goal: 3rd party software distribution
20+
21+Key results:
22+- Virtual desks
23+- Tools to manipulate and inspect them
24+
25+Background reading:
26+- Thread about 3rd party software distribution: https://groups.google.com/a/urbit.org/g/dev/c/zNK_-Z4gDNk/m/FM4PP2kxCAAJ
27+- Description of merge strategies: https://github.com/urbit/urbit/blob/729802102b788fd51e4e9afe8580b370f5119073/pkg/arvo/gen/hood/merge/help.txt
28+
29+Step 1 is to build a simple tool to see the difference between desks. For an example of a file diff, try running `-diff %/app/lens/hoon %/app/glob/hoon`. Mainly, we want a recursive version of that, with options to display the full diff or just list the files which changed. Ideally we'd also have a 3-way diff, but that could be delayed.
30+
31+Step 2 is the hard one: as described in that urbit-dev thread, add "virtual" desks to clay. These represent the continual merge of several other desks. Their main properties are:
32+
33+- No committing directly to the desk, the only permitted manual modification is to change the list of source desks (including order and merge strategy)
34+- Every time a source desk is updated, the next commit is a brand new merge of all the source desks, in order according to their merge strategy. Possibly the previous version should also be listed as a parent.
35+- The list of source desks is ordered, includes a merge strategy, and each desk may be pinned to a revision.
36+
37+Step 3 is to make the %home desk virtual. There should probably be another local desk which is a source of %home for local modifications. This step could be a bit finicky but shouldn't be too hard.
38+
39+With these steps complete, the infrastructure side of 3rd party software distribution should be complete.
40+
41+Future work:
42+- UI stuff
43+- Port forward pottery for debugging (https://github.com/urbit/pottery)
44+
45+## Compensation
46+
47+* Parts 1 & 2: Two stars, one awarded after a month of work, another awarded after completion of Part 2.
48+* Part 3: One star awarded after one month of work, two additional stars awarded after completion of Part 3, which is completion of the project.
49+* Total: 5 stars for ~2.5 months of estimated work.
50+* "One month of work," if not resulting in a finished milestone, will be evaluated by the Tlon engineer working on the project with you for determination of reward eligibility.
content/grants/ua-collaborative-text-editor.md → content/grants/apprenticeships/ua-collaborative-text-editor.mdrenamed

The content is the same.

content/grants/ua-filesharer.md → content/grants/apprenticeships/ua-filesharer.mdrenamed

The content is the same.

content/grants/ua-heads-up-poker.md → content/grants/apprenticeships/ua-heads-up-poker.mdrenamed

The content is the same.

content/grants/ua-invoice-system.md → content/grants/apprenticeships/ua-invoice-system.mdrenamed

The content is the same.

content/grants/ua-marketplace.md → content/grants/apprenticeships/ua-marketplace.mdrenamed

The content is the same.

content/grants/analytics-script.md → content/grants/bounties/analytics-script.mdrenamed

The content is the same.

content/grants/antechamber.md → content/grants/bounties/antechamber.mdrenamed

The content is the same.

content/grants/bart-train-tracker-landscape-tile.md → content/grants/bounties/bart-train-tracker-landscape-tile.mdrenamed

The content is the same.

content/grants/bitcoin-full-node-provider-and-wallet.md → content/grants/bounties/bitcoin-full-node-provider-and-wallet.mdrenamed

The content is the same.

content/grants/bitcoin-key-derivation.md → content/grants/bounties/bitcoin-key-derivation.mdrenamed

The content is the same.

content/grants/bitcoin-node-json-rpc-api-part-1.md → content/grants/bounties/bitcoin-node-json-rpc-api-part-1.mdrenamed

The content is the same.

content/grants/bitcoin-node-json-rpc-api-part-2.md → content/grants/bounties/bitcoin-node-json-rpc-api-part-2.mdrenamed

The content is the same.

content/grants/bitcoin-node-json-rpc-api-part-3.md → content/grants/bounties/bitcoin-node-json-rpc-api-part-3.mdrenamed

The content is the same.

content/grants/bitcoin-node-json-rpc-api-part-4.md → content/grants/bounties/bitcoin-node-json-rpc-api-part-4.mdrenamed

The content is the same.

content/grants/bitcoin-wallet-on-bridge.md → content/grants/bounties/bitcoin-wallet-on-bridge.mdrenamed

The content is the same.

content/grants/boston-t-train-tracker-landscape-tile.md → content/grants/bounties/boston-t-train-tracker-landscape-tile.mdrenamed

The content is the same.

content/grants/bounties/bounty-vane-documentation.mdnew file+95
@@ -0,0 +1,95 @@
1++++
2+title = "Create Vane Documentation"
3+date = 2021-03-01
4+[taxonomies]
5+grant_type = ["bounties"]
6+grant_category = ["Documentation"]
7+[extra]
8+image = ""
9+description = "Create vane documentation for clay, eyer, iris, jael, and behn"
10+reward = 5
11+assignee = "~tinnus-napbus"
12+id = ""
13+completed = false
14+work_request_link = "https://airtable.com/shr4qt9t9kz7RaOIa?prefill_Grant+ID=B0025&prefill_Grant+Name=Create%20vane%20Documentation"
15++++
16+
17+## Overview
18+
19+Creating and maintaining great documentation is an ongoing challenge for any project, ours included. The importance of documentation for Urbit is greater than most projects though, since so much of what we're doing is entirely novel.
20+
21+This grant will have you work within the Urbit Foundation and Tlon to improve/create select portions of our documentation over the course of three months (April, May and June).
22+
23+## Scope
24+
25+The goal over these three months is to more fully document Arvo's vanes. At present, the documentation is sporadic: some vanes have good TODO:[explanation-style] () documentation, others have good TODO:[API References] ()—some even have both. In the case of `eyre` and `clay`, which are arguably two of the most important vanes, we have neither—the explanations are outdated and overly technical, and the API reference is missing, incomplete, and outdated.
26+
27+Your task is to fill in the blanks and provide complete documentation that leaves the reader with an understanding of *how to use the vanes.* Understanding *how they work* is of secondary importance, so:
28+
29+- Explanations should be high level and light-to-free of code. The explanation should also serve to provide an overview of what kinds of capabilities the vane has in the first place.
30+- API reference for each vane should be complete
31+- Usage guides for common tasks would be very helpful
32+
33+Here's a sketch of what's probably needed for each vane in order of priority:
34+
35+### 1) [clay](https://urbit.org/docs/arvo/clay/clay)
36+
37+The clay documentation is generally out of date, and the explanations are overly geared at describing how the internals work over what the interface is and what you can do with it. Some of the explanatory material is actually pretty good (like the [Architecture](https://urbit.org/docs/arvo/clay/architecture/) doc), but much of it is too dense.
38+
39+For clay we want:
40+
41+* Proper API Reference documentation
42+* Guides for common tasks and capabilities
43+* Updated explanations of the key concepts and capabilities that [avoid becoming overly technical](https://urbit.org/docs/arvo/clay/local-reads/)
44+
45+A contributor (~sovmep-ripsum) has recently been doing a lot of work on Clay and has offered to give you some direction on this, which will be helpful coming from the perspective of someone who's recently had to learn clay. He also wrote up some [notes](https://docs.google.com/document/d/10b5oC_Jcdq7Ex4iwf0mRjquEfolmUQvbs5YFJulsXa0/edit?ts=606cddf2) which you can use.
46+
47+### 2) [eyre](https://urbit.org/docs/arvo/eyre/eyre/)
48+
49+The eyre documentation is completely out of date and needs to be rewritten, particularly where the explanation is concerned. Fortunately, you're not starting from scratch with the API documentation, for which there's an [open PR](https://github.com/urbit/docs/pull/981) that needs to be brought through to completion.
50+
51+For eyre we want:
52+
53+* Complete API Reference documentation
54+* Guides for common tasks and capabilities
55+* Explanations of key concepts and capabilities
56+
57+### 3) [iris](https://urbit.org/docs/arvo/iris/)
58+
59+Iris has no explanation whatsoever, but does have an API reference.
60+
61+For iris we want:
62+
63+* Explanations of key concepts and capabilities
64+* Guides for common tasks and capabilities
65+
66+### 4) [jael](https://urbit.org/docs/arvo/jael)
67+
68+Jael has no explanation whatsoever, but does have an API reference.
69+
70+For jael we want:
71+
72+* Explanations of key concepts and capabilities
73+* Guides for common tasks and capabilities
74+
75+### 5) [behn](https://urbit.org/docs/arvo/behn/behn/), [dill](https://urbit.org/docs/arvo/dill/dill), [ames](https://urbit.org/docs/arvo/ames/ames)
76+
77+These vanes already have either minimal but viable explanations (behn, dill) or very good explanations (ames). They've all also got API Reference docs. None of them have usage guides that demonstrate how to work with the APIs though.
78+
79+Adding more documentation to these vanes is lowest priority, but if you have ideas for contribution they'd be welcome.
80+
81+## Requirements/Resources
82+
83+Work should be submitted as pull requests against the [docs](https://github.com/urbit/docs) repository, and is to be considered complete upon review and merge.
84+
85+You'll work with the Director of urbit.org and the Tlon docs team regularly, and should expect to meet weekly or biweekly to check in and share progress. Access to Tlon's infrastructure engineers will be provided for whenever you have technical questions.
86+
87+## Compensation
88+
89+We're targeting a three month period to complete the above, but may seek to extend the engagement. During this time, compensation is as follows:
90+
91+* One star for completion of clay docs
92+* One star for completion of eyre docs
93+* One star for completion of iris and jael docs
94+* One star upon completion of all of the above docs
95+* One additional star awarded at the director's discretion for exemplary work
content/grants/content-saver.md → content/grants/bounties/content-saver.mdrenamed

The content is the same.

content/grants/cta-train-tracker-landscape-tile.md → content/grants/bounties/cta-train-tracker-landscape-tile.mdrenamed

The content is the same.

content/grants/display-eth-data.md → content/grants/bounties/display-eth-data.mdrenamed

The content is the same.

content/grants/educational-guide-todomvc-urbit-edition.md → content/grants/bounties/educational-guide-todomvc-urbit-edition.mdrenamed

The content is the same.

content/grants/ethereum-abi-parser.md → content/grants/bounties/ethereum-abi-parser.mdrenamed

The content is the same.

content/grants/gall-api-documentation.md → content/grants/bounties/gall-api-documentation.mdrenamed

The content is the same.

content/grants/go-airlock-library.md → content/grants/bounties/go-airlock-library.mdrenamed

The content is the same.

content/grants/haskell-airlock-library.md → content/grants/bounties/haskell-airlock-library.mdrenamed

The content is the same.

content/grants/host-three-college-university-urbit-meetups-1.md → content/grants/bounties/host-three-college-university-urbit-meetups-1.mdrenamed

The content is the same.

content/grants/host-three-college-university-urbit-meetups-2.md → content/grants/bounties/host-three-college-university-urbit-meetups-2.mdrenamed

The content is the same.

content/grants/host-three-college-university-urbit-meetups-3.md → content/grants/bounties/host-three-college-university-urbit-meetups-3.mdrenamed

The content is the same.

content/grants/host-three-virtual-urbit-meetups.md → content/grants/bounties/host-three-virtual-urbit-meetups.mdrenamed

The content is the same.

content/grants/host-two-urbit-meetups-1.md → content/grants/bounties/host-two-urbit-meetups-1.mdrenamed

The content is the same.

content/grants/host-two-urbit-meetups-10.md → content/grants/bounties/host-two-urbit-meetups-10.mdrenamed

The content is the same.

content/grants/host-two-urbit-meetups-11.md → content/grants/bounties/host-two-urbit-meetups-11.mdrenamed

The content is the same.

content/grants/host-two-urbit-meetups-2.md → content/grants/bounties/host-two-urbit-meetups-2.mdrenamed

The content is the same.

content/grants/host-two-urbit-meetups-3.md → content/grants/bounties/host-two-urbit-meetups-3.mdrenamed

The content is the same.

content/grants/host-two-urbit-meetups-4.md → content/grants/bounties/host-two-urbit-meetups-4.mdrenamed

The content is the same.

content/grants/host-two-urbit-meetups-5.md → content/grants/bounties/host-two-urbit-meetups-5.mdrenamed

The content is the same.

content/grants/host-two-urbit-meetups-6.md → content/grants/bounties/host-two-urbit-meetups-6.mdrenamed

The content is the same.

content/grants/host-two-urbit-meetups-7.md → content/grants/bounties/host-two-urbit-meetups-7.mdrenamed

The content is the same.

content/grants/host-two-urbit-meetups-8.md → content/grants/bounties/host-two-urbit-meetups-8.mdrenamed

The content is the same.

content/grants/host-two-urbit-meetups-9.md → content/grants/bounties/host-two-urbit-meetups-9.mdrenamed

The content is the same.

content/grants/matrices-in-hoon.md → content/grants/bounties/matrices-in-hoon.mdrenamed

The content is the same.

content/grants/network-explorer-data-pipeline-http-api.md → content/grants/bounties/network-explorer-data-pipeline-http-api.mdrenamed

The content is the same.

content/grants/open-street-maps-data-importation.md → content/grants/bounties/open-street-maps-data-importation.mdrenamed

The content is the same.

content/grants/overhaul-the-urbitorg-website.md → content/grants/bounties/overhaul-the-urbitorg-website.mdrenamed

The content is the same.

content/grants/staff-the-urbit-help-desk-1.md → content/grants/bounties/staff-the-urbit-help-desk-1.mdrenamed

The content is the same.

content/grants/staff-the-urbit-help-desk-2.md → content/grants/bounties/staff-the-urbit-help-desk-2.mdrenamed

The content is the same.

content/grants/staff-the-urbit-helpdesk-east.md → content/grants/bounties/staff-the-urbit-helpdesk-east.mdrenamed

The content is the same.

content/grants/staff-the-urbit-helpdesk-west.md → content/grants/bounties/staff-the-urbit-helpdesk-west.mdrenamed

The content is the same.

content/grants/thread-documentation.md → content/grants/bounties/thread-documentation.mdrenamed

The content is the same.

content/grants/tor-nodes-relay-search-tile.md → content/grants/bounties/tor-nodes-relay-search-tile.mdrenamed

The content is the same.

content/grants/typescript-airlock-library.md → content/grants/bounties/typescript-airlock-library.mdrenamed

The content is the same.

content/grants/ucal-google-and-outlook-integration.md → content/grants/bounties/ucal-google-and-outlook-integration.mdrenamed

The content is the same.

content/grants/udon-syntax-highlighter.md → content/grants/bounties/udon-syntax-highlighter.mdrenamed

The content is the same.

content/grants/unit-tests-for-json-parsing.md → content/grants/bounties/unit-tests-for-json-parsing.mdrenamed

The content is the same.

content/grants/unit-tests-for-pure-algorithms.md → content/grants/bounties/unit-tests-for-pure-algorithms.mdrenamed

The content is the same.

content/grants/unit-tests-for-sha-functions.md → content/grants/bounties/unit-tests-for-sha-functions.mdrenamed

The content is the same.

content/grants/unit-tests-for-zuse-cryptographic-functions.md → content/grants/bounties/unit-tests-for-zuse-cryptographic-functions.mdrenamed

The content is the same.

content/grants/urbit-community-concierge-east-coast-2q2021.md → content/grants/bounties/urbit-community-concierge-east-coast-2q2021.mdrenamed

The content is the same.

content/grants/urbit-community-concierge-east-coast.md → content/grants/bounties/urbit-community-concierge-east-coast.mdrenamed

The content is the same.

content/grants/urbit-community-concierge-west-coast-2q2021.md → content/grants/bounties/urbit-community-concierge-west-coast-2q2021.mdrenamed

The content is the same.

content/grants/urbit-community-concierge-west-coast.md → content/grants/bounties/urbit-community-concierge-west-coast.mdrenamed

The content is the same.

content/grants/verifying-urbit-id-on-keybase.md → content/grants/bounties/verifying-urbit-id-on-keybase.mdrenamed

The content is the same.

content/grants/video-content-manager.md → content/grants/bounties/video-content-manager.mdrenamed

The content is the same.

content/grants/volt-lightning-on-urbit.md → content/grants/bounties/volt-lightning-on-urbit.mdrenamed

The content is the same.

content/grants/web-scraper.md → content/grants/bounties/web-scraper.mdrenamed

The content is the same.

content/grants/calendar-ui.mddeleted−53
@@ -1,53 +0,0 @@
1−+++
2−title = "Calendar UI"
3−date = 2020-07-16
4−[taxonomies]
5−grant_type = ["proposals"]
6−grant_category = ["App Dev: Arvo"]
7−[extra]
8−image = ""
9−description = "Build a Landscape-native calendar UI"
10−reward = 2
11−assignee = "finled-bansel"
12−id = "1555464949"
13−completed = false
14−link = ""
15−+++
16−
17−# Purpose
18−
19−A calendar is an indispensible personal tool to many people. A [previous proposal](https://grants.urbit.org/proposals/1851255517) has started work on an Urbit-native calendar. This previous proposal seeks to create a parser and a Gall agent to manage the data layer of a calendar app.
20−
21−The current proposal aims to create a Landscape tile and app to improve the accessibility of a Calendar Gall app. The Calendar UI will provide several screens to interact with the calendar. These are a monthly view, a daily view and a page to create new events.
22−
23−# Implementation and deliverables
24−
25−The UI will be backed by the calendar app implementation described in the aforementioned previous proposal. In order to allow the parallel implementation of a UI and the Gall app, this proposal will be executed in two stages.
26−
27−The first stage is the development of working prototypes of the screens that the calendar will initially support. These include:
28− - a monthly view with clickable dates to daily views;
29− - a daily view that lists the events in chronological order with a short description
30− - a form to create new events with fields for the required properties per RFC 5545.
31−
32−The deliverables will be functional web pages that can be integrated with Landscape. The screens will be built entirely with components from the [Indigo-react](https://github.com/urbit/indigo-react) library.
33−The UI will be built with the assumption that event participants are ships.
34−
35−The second stage is to integrate the screens with the Gall agent implemented as part of the first proposal. This takes a dependency on a correctly functioning calendar Gall app. The requisite
36−
37−# Basis for future integration
38−
39−These pages can provide the basis for UX experiments and integrations with other parts of Landscape. One possibility is to integrate notebook posts with the timeline of a calendar, allowing a temporal exploration of the notebook posts a ship has seen.
40−
41−## Milestones
42−
43−
44−### Functional pages
45−1 stars
46−Build the necessary pages that will allow Landscape to interact with a Calendar Gall app
47−
48−
49−### Working integration with Gall app
50−1 stars
51−Fully capable of importing an .ics calendar, creating new events, looking through existing events in the calendar of a ship.
52−
53−
content/grants/a-book-about-urbit.md → content/grants/proposals/a-book-about-urbit.mdrenamed

The content is the same.

content/grants/a-collaborative-web-mapping-system-for-urbit.md → content/grants/proposals/a-collaborative-web-mapping-system-for-urbit.mdrenamed

The content is the same.

content/grants/art-by-urbit.md → content/grants/proposals/art-by-urbit.mdrenamed

The content is the same.

content/grants/proposals/calendar-ui.mdnew file+54
@@ -0,0 +1,54 @@
1++++
2+title = "Calendar UI"
3+date = 2021-01-01
4+[taxonomies]
5+grant_type = ["proposals"]
6+grant_category = ["App Dev: Other"]
7+[extra]
8+image = ""
9+description = "Develop a UI for improved access to the Calendar Gall app"
10+reward = 3
11+assignee = "~fabnev-hinmur"
12+grants_id = ""
13+completed = true
14++++
15+
16+
17+## Purpose
18+
19+A calendar is an indispensible personal tool to many people. A previous proposal has started work on an Urbit-native calendar.
20+This previous proposal seeks to create a parser and a Gall agent to manage the data layer of a calendar app.
21+
22+The current proposal aims to create a Landscape tile and app to improve the accessibility of a Calendar Gall app.
23+The Calendar UI will provide several screens to interact with the calendar. These are a daily view, weekly view, monthly view,
24+and yearly view, along with pages to create and edit calendars and events.
25+
26+## Deliverables
27+
28+The UI will be backed by the Gall calendar app implementation (now known as 'ucal') mentioned above. The UI design will be
29+based on the Google Calendar layout and built with components from the Indigo-react library.
30+
31+The UI will be written in Typescript with the React framework, following the Landscape structure as much as possible. The goal is to have a UI that can be incorporated as part of Landscape if desired.
32+
33+List of Features:
34+
35+1. Daily View
36+2. Weekly View
37+3. Monthly View
38+4. Yearly View
39+5. Create / Edit Calendar View
40+6. Create / Edit Event View
41+7. Full CRUD operations for calendars
42+8. Full CRUD operations for events
43+9. Toggle calendar display
44+
45+## Future features
46+
47+There will be additional UI features necessary to allow users to interact with other ships' calendars. Specifically, retrieving events that a user is invited to, RSVPing to events, subscribing to other ships' calendars, modifying other calendars with requisite permissions, and perhaps requesting additional permissions on other calendars. Many of these features are in progress but still require significant development and testing.
48+
49+
50+## Milestones
51+
52+Completion of all 9 features: 3 stars
53+
54+
content/grants/calendar.md → content/grants/proposals/calendar.mdrenamed

The content is the same.

content/grants/comprehensive-local-server-and-mum-explanation-video.md → content/grants/proposals/comprehensive-local-server-and-mum-explanation-video.mdrenamed

The content is the same.

content/grants/cross-platform-desktop-urbit-app.md → content/grants/proposals/cross-platform-desktop-urbit-app.mdrenamed

The content is the same.

content/grants/docker-image-for-cloud-container-orchestration.md → content/grants/proposals/docker-image-for-cloud-container-orchestration.mdrenamed

The content is the same.

content/grants/escape.md → content/grants/proposals/escape.mdrenamed

The content is the same.

content/grants/graph-store-documentation-guide.md → content/grants/proposals/graph-store-documentation-guide.mdrenamed

The content is the same.

content/grants/hoon-001-learner-efficiency-and-early-learner-resources.md → content/grants/proposals/hoon-001-learner-efficiency-and-early-learner-resources.mdrenamed

The content is the same.

content/grants/links-in-urbit-reference-docs.md → content/grants/proposals/links-in-urbit-reference-docs.mdrenamed

The content is the same.

content/grants/llelogram.md → content/grants/proposals/llelogram.mdrenamed

The content is the same.

content/grants/matrixriotim-bridge-bot.md → content/grants/proposals/matrixriotim-bridge-bot.mdrenamed

The content is the same.

content/grants/minimal-urbit-os.md → content/grants/proposals/minimal-urbit-os.mdrenamed

The content is the same.

content/grants/ragnarok-online-on-urbit.md → content/grants/proposals/ragnarok-online-on-urbit.mdrenamed

The content is the same.

content/grants/search-in-groups.md → content/grants/proposals/search-in-groups.mdrenamed

The content is the same.

content/grants/-smol-future-sustained-knowledge-sharing-and-marketing.md → content/grants/proposals/smol-future-sustained-knowledge-sharing-and-marketing.mdrenamed

The content is the same.

content/grants/proposals/star-documentation-proposal.mdnew file+37
@@ -0,0 +1,37 @@
1++++
2+title = "How to Buy a Star: a Guide"
3+date = 2021-06-08
4+[taxonomies]
5+grant_type = ["proposals"]
6+grant_category = ["Documentation"]
7+[extra]
8+image = ""
9+description = "Create a guide with helpful vocabulary and essential how-tos"
10+reward = 1
11+assignee = "~sonnep-ribbep"
12+id = "P0016"
13+completed = false
14+link = ""
15++++
16+
17+## Vision
18+
19+Buying a star can be a daunting prospect, even for those who have owned a planet for some time. A star is much more expensive than a planet, and it comes with new and confusing vocabulary. What's a naked star? Are some stars in lockup? Is mine in lockup? If it is in lockup, how does it get unlocked?
20+
21+If the prospective buyer is not using an established website such as OpenSea, and is instead buying from an individual, these problems become much worse. What makes a star commodity grade? How can the buyer verify the status of the star?
22+
23+This documentation will function as a Guide for the Perplexed. It will tell the buyer what to look for, and how to look for it, in entirely non-technical language. More daunting tasks such as verifying the star status on Hoon and/or Ethereum will be described clearly and plainly. By following this guide, the buyer will be able to verify the star's status, not merely trust the seller.
24+
25+## Design
26+
27+The documentation will be entirely text. Since I know few of the answers to these questions, I will post in The Marketplace and other channels on Urbit to seek community input. I will gather knowledge from anyone willing to share, and compile an easy-to-read and well-sourced document that can be posted and shared anywhere useful.
28+
29+## Me
30+
31+I'm a full-stack software engineer and former lawyer. I'm adept at navigating new domains and sharing what I've learned in an accessible and pleasant way.
32+
33+## Milestones
34+
35+### Documentation is merged
36+1 stars
37+1-2 months, probably toward the end of July 2021
content/grants/the-complete-guide-to-gall-and-landscape.md → content/grants/proposals/the-complete-guide-to-gall-and-landscape.mdrenamed

The content is the same.

content/grants/translate-key-parts-of-urbitorg-into-german.md → content/grants/proposals/translate-key-parts-of-urbitorg-into-german.mdrenamed

The content is the same.

content/grants/translate-key-parts-of-urbitorg-into-korean.md → content/grants/proposals/translate-key-parts-of-urbitorg-into-korean.mdrenamed

The content is the same.

content/grants/translate-key-parts-of-urbitorg-into-norwegian.md → content/grants/proposals/translate-key-parts-of-urbitorg-into-norwegian.mdrenamed

The content is the same.

content/grants/translate-key-parts-of-urbitorg-into-spanish.md → content/grants/proposals/translate-key-parts-of-urbitorg-into-spanish.mdrenamed

The content is the same.

content/grants/try-urbit-website.md → content/grants/proposals/try-urbit-website.mdrenamed

The content is the same.

content/grants/up-to-date-hoon-reference-card.md → content/grants/proposals/up-to-date-hoon-reference-card.mdrenamed

The content is the same.

content/grants/urbian-a-customized-linux-distribution-for-urbit-appliances.md → content/grants/proposals/urbian-a-customized-linux-distribution-for-urbit-appliances.mdrenamed

The content is the same.

content/grants/urbit-api-for-elixir.md → content/grants/proposals/urbit-api-for-elixir.mdrenamed

The content is the same.

content/grants/urbit-event-series.md → content/grants/proposals/urbit-event-series.mdrenamed

The content is the same.

content/grants/urbit-explainer-video.md → content/grants/proposals/urbit-explainer-video.mdrenamed

The content is the same.

content/grants/urbit-http-api-for-emacs-elisp.md → content/grants/proposals/urbit-http-api-for-emacs-elisp.mdrenamed

The content is the same.

content/grants/urbit-http-api-for-kotlin.md → content/grants/proposals/urbit-http-api-for-kotlin.mdrenamed

The content is the same.

content/grants/urbit-http-api-for-rust.md → content/grants/proposals/urbit-http-api-for-rust.mdrenamed

The content is the same.

content/grants/urbit-http-interface-java-edition.md → content/grants/proposals/urbit-http-interface-java-edition.mdrenamed

The content is the same.

content/grants/urbit-http-library-for-ruby.md → content/grants/proposals/urbit-http-library-for-ruby.mdrenamed

The content is the same.

content/grants/urbit-lfs-filehosting.md → content/grants/proposals/urbit-lfs-filehosting.mdrenamed

The content is the same.

content/grants/urbit-online-meetup.md → content/grants/proposals/urbit-online-meetup.mdrenamed

The content is the same.

content/grants/urbit-react-cookbook.md → content/grants/proposals/urbit-react-cookbook.mdrenamed

The content is the same.

content/grants/urbit-ship-and-star-hosting-and-troubleshooting-docs.md → content/grants/proposals/urbit-ship-and-star-hosting-and-troubleshooting-docs.mdrenamed

The content is the same.

content/grants/webrtc-gall-agent-and-external-app.md → content/grants/proposals/webrtc-gall-agent-and-external-app.mdrenamed

The content is the same.

content/grants/submit-proposal.mdnew file+67
@@ -0,0 +1,67 @@
1++++
2+title = "Guide to Creating a Grant Proposal"
3+weight = 1
4+description = "A comprehensive guide to creating a grant proposal."
5++++
6+
7+The Urbit project relies on our community to help realize its potential. While the Foundation specifies the direction of
8+development through bounties, we encourage anyone with an idea about how to improve Urbit to submit a grant proposal. This
9+guide will describe the different types of proposals, the requested format, and the entire workflow for a successful project.
10+
11+### Types of Proposals
12+
13+While we will entertain just about any idea that comes from the community, we are particularly interested in "capital goods":
14+projects that provide new capabilities to the widest number of users or developers or add tooling to the platform. Recent
15+examples are [Bitcoin](../bitcoin-full-node-provider-and-wallet) integration, [WebRTC](../webrtc-gall-agent-and-external-app)
16+integration, or the [Urbit Large File Storage](../urbit-lfs-filehosting) project.
17+
18+Proposal types include:
19+
20+ - Core Development - kernal or runtime development
21+ - Application Development - userspace development of specific applications
22+ - Developer Tools - Libraries, APIs, unit tests, etc.
23+ - Design Work - design work for the urbit.org website
24+ - Documentation - writing guides or website content
25+ - Community - organizing events and meetups, staffing the help desk
26+
27+We have need for lots of different skill sets&mdash;not just coding.
28+
29+
30+### Proposal Format
31+
32+Your proposal should include the following sections:
33+
34+ - Project name
35+ - Brief description of project
36+ - Proposal body including:
37+ - Project Overview
38+ - Project Scope
39+ - Detailed behavior description
40+ - Detailed design description
41+ - Your experience
42+ - Why you are the right person for this project
43+ - Milestones:
44+ - Any sub-goals of project
45+ - Specific deliverables
46+ - Expected timeframes
47+ - Expected compensation in Stars
48+
49+### Proposal Submission and Project Workflow
50+
51+Once you have your proposal in order, submit it using the **[Propose a Project](https://airtable.com/shrCi54rEDxgSZr3z)** form.
52+From this point, your project will go through these stages:
53+
54+ - **Draft**: A team member will reach out to schedule a meeting with you to discuss your proposal in detail. There may be
55+ some modifications requested to get approval. Once we come to agreement you will create markdown for your project by
56+[downloading the template](https://drive.google.com/file/d/1a2zZXxmzcME5vJHDpLpKtExcqzg-V3rD/view?usp=sharing), editing it with
57+your proposal information, then submitting a [pull request](https://github.com/urbit/urbit.org/compare) against the urbit.org repo
58+ on [github](https://github.com/urbit/urbit.org).
59+ - **Paperwork**: Once your proposal pull request is merged, you will need to submit some paperwork (contract, IRS forms, etc.)
60+ - **Live**: When the paperwork is complete, you can start work on your project.
61+ - **Milestone**: When you complete a milestone (or the entire project), you will create an invoice an submit it using the
62+[Submit Invoice](https://airtable.com/shrXXCs1uaxtNSBcg) form.
63+ - **Payment**: If your work is approved by your reviewer, your payment will enter the payment queue. It can take up to 2 weeks to
64+ receive your payment, since we make transfers on the 2nd and 17th of the month.
65+
66+Don't be concerned if you are unclear about any of these details. We will be happy to guide you once your project enters the
67+workflow.
content/using/id/guide-to-breaches.md+37−43
@@ -6,27 +6,36 @@ template = "doc.html"
6
6
7An important concept on the [Ames](@/docs/arvo/ames/ames.md) network is that of continuity. Continuity refers to how ships remember the order of their own network messages and the network messages of others -- these messages are numbered, starting from zero. A _breach_ is when ships on the network agree to forget about this sequence and treat one or more ships like they are brand new.
7An important concept on the [Ames](@/docs/arvo/ames/ames.md) network is that of continuity. Continuity refers to how ships remember the order of their own network messages and the network messages of others -- these messages are numbered, starting from zero. A _breach_ is when ships on the network agree to forget about this sequence and treat one or more ships like they are brand new.
8
8
9−There are two kinds of breaches: **personal breaches** and **network breaches**.
9+There are two kinds of breaches: (personal) **breaches** and **network breaches**.
10−
10+
11−## Personal Breaches
11+## Breaches
12−
12+
13−Ships on the Ames network sometimes need to reset their continuity. A personal breach is when an individual ship announces to the network: "I forgot who I am, let's start over from scratch." That is, it clears its own event log and sends an announcement to the network, asking all ships that have communicated with it to reset its networking information in their state. This makes it as though the ship was just started for the first time again, since everyone on the network has forgotten about it.
13+Ships on the Ames network sometimes need to reset their continuity. A breach is
14−
14+when an individual ship announces to the network: "I forgot who I am, let's
15+start over from scratch." That is, it clears its own event log and sends an
16+announcement to the network, asking all ships that have communicated with it to
17+reset its networking information in their state. This makes it as though the
18+ship was just started for the first time again, since everyone on the network
19+has forgotten about it.
20+
15−Personal breaches often fix connectivity issues, but should only be used as a
21+Breaches often fix connectivity issues, but should only be used as a last
16−last resort. Before performing a personal breach, look at alternative fixes in
22+resort. Before performing a breach, look at alternative fixes in the [Ship
17−the [Ship Troubleshooting](../ship-troubleshooting) guide. Also reach out for
23+Troubleshooting](../ship-troubleshooting) guide. Also reach out for help in the
18−help in the Help channel in the Urbit Community group
24+Help channel in the Urbit Community group `~bitbet-bolbel/urbit-community`, or,
19−`~bitbet-bolbel/urbit-community`, or, failing that, in the
20−`#ship-starting-support` channel in our [Discord
25+failing that, in the `#ship-starting-support` channel in our [Discord
21server](https://discord.gg/n9xhMdz) to see if there is another option.
26server](https://discord.gg/n9xhMdz) to see if there is another option.
27+Connectivity issues are typically related to a bug, and you may be able to help
28+us fix it by emailing us at `support@urbit.org`.
22
29
23−There are two types of personal breaches - one where your Ethereum ownership address
30+There are two separate sequences of actions you need to take in order to breach.
31+One flow is for when you wish to keep Ethereum ownership address of the ship the
24−remains the same, and one where you are switching to a new Ethereum ownership
32+same, and the other is for when you are transferring the ship to a new Ethereum
25−address. We make the emphasis about the Ethereum _ownership_ address as
33+ownership address. We make the emphasis about the Ethereum _ownership_ address
26−changing your [proxies](@/docs/glossary/proxies.md) does not require a breach.
34+as changing your [proxies](@/docs/glossary/proxies.md) does not require a
35+breach.
27
36
28−If you will be keeping the same Ethereum ownership address and would like to perform a
37+If you will be keeping your ship at the same Ethereum ownership address and
29−personal breach, follow the steps below.
38+would like to perform a breach, follow the steps below.
30
39
31- Go to [bridge.urbit.org](https://bridge.urbit.org) and log into your identity.
40- Go to [bridge.urbit.org](https://bridge.urbit.org) and log into your identity.
32- Click on `OS: Urbit OS Settings` at the bottom, then click `Reset Networking Keys`.
41- Click on `OS: Urbit OS Settings` at the bottom, then click `Reset Networking Keys`.
@@ -38,7 +47,7 @@ personal breach, follow the steps below.
38- Delete your keyfile after successfully booting.
47- Delete your keyfile after successfully booting.
39- Rejoin your favorite chat channels and subscriptions.
48- Rejoin your favorite chat channels and subscriptions.
40
49
41−If you are switching to a new Ethereum ownership address you will have the
50+If you are transferring a ship to a new Ethereum ownership address you will have the
42choice as to whether or not you want to breach. This is to cover the case when
51choice as to whether or not you want to breach. This is to cover the case when
43you are transferring to another address you own. The process here is slightly different.
52you are transferring to another address you own. The process here is slightly different.
44
53
@@ -61,30 +70,15 @@ you are transferring to another address you own. The process here is slightly di
61- Delete your keyfile after successfully booting.
70- Delete your keyfile after successfully booting.
62- Rejoin your favorite chat channels and subscriptions.
71- Rejoin your favorite chat channels and subscriptions.
63
72
64−Performing a personal breach on your ship increments an integer value called
65−your ship's _life_ by one, which refers to your ship's [Azimuth](@/docs/azimuth/azimuth.md) _key
66−revision number_. This value is utilized by
67−Ames and Jael to ensure that you are
68−communicating with a ship created using its most recent set of keys. Your
69−ship's life is written at the end of the name of its keyfile, e.g.
70−`sampel-palnet-4.key`. Changing the Etherum address that holds the Urbit ID,
71−called _reticketing_, increments a number called the ship's _rift_ by one in
72−addition to incrementing your ship's life.
73−Rift refers to your ship's Azimuth _continuity number_.
74−
75−You can check your current life and rift number by running the
76−`+keys our` generator in Dojo. You can inspect another ship's life and rift can be checked by
77−running `+keys ~sampel-palnet`.
78−
79−
80## Network Breaches
73## Network Breaches
81
74
82−A network breach is an event where all ships on the network are required to update to a new continuity era. Network breaches happen when an Arvo update is released that is too large to release over the air. The current continuity era is given by a value in Ames, our networking vane, that is incremented when a network breaches; only ships with the same such value are able to communicate with one another.
75+Network breaches were events where all ships on the network were required to
76+update to a new continuity era. Network breaches happened when an Arvo update
77+was released that could not be implemented via an [OTA
78+update](@/docs/glossary/ota-updates.md). The continuity era is given by an
79+integer in Ames that is incremented when the network breaches. Only ships with
80+the same such value are able to communicate with one another. The most recent
81+network breach occurred in December 2020, and we expect it to have been the final one.
83
82
84−If a network breach is happening, follow the steps below.
83+If another network breach does occur, we will provide accompanying documentation
85−
84+on what to do to transfer your ship and all of its data to the new era.
86−- Delete your old Urbit binary.
87−- Delete or archive your old pier.
88−- Download the new Urbit binary by following the instructions in the [Install page](@/getting-started/_index.md).
89−- Create a new pier by booting your ship with your key, according to the instructions on the install page. (Note: You do _not_ need to use a new key to boot into a new continuity era.)
90−- Rejoin your favorite chat channels and subscriptions.
content/using/os/getting-started.md+1−1
@@ -216,7 +216,7 @@ When this happens, back up any files you'd like to save, shut down your urbit, a
216
216
217You can check your ship's _life_ and _rift_ number by running `+keys our` in
217You can check your ship's _life_ and _rift_ number by running `+keys our` in
218dojo. You can inspect another ship's life and rift number by running `+keys
218dojo. You can inspect another ship's life and rift number by running `+keys
219−~sampel-palnet`. For information on what life and rift are, see [Guide to Breaches](@/using/id/guide-to-breaches.md).
219+~sampel-palnet`. For information on what life and rift are, see [Life and Rift](@/docs/azimuth/life-and-rift.md).
220
220
221## DNS proxying {#dns-proxying}
221## DNS proxying {#dns-proxying}
222
222
sass/_main.scss+15
@@ -314,6 +314,15 @@ nav ul.docs {
314 line-height: 30px;
314 line-height: 30px;
315}
315}
316
316
317+.doc {
318+ > *:not(pre) {
319+ @extend .measure-wide;
320+ }
321+ pre {
322+ max-width: 60em;
323+ }
324+}
325+
317 // pagination
326 // pagination
318nav.previous, nav.next {
327nav.previous, nav.next {
319 max-width: 40% !important;
328 max-width: 40% !important;
@@ -452,6 +461,12 @@ pre {
452 padding: 1.25rem;
461 padding: 1.25rem;
453 overflow-x: scroll;
462 overflow-x: scroll;
454 @extend .bg-gray5;
463 @extend .bg-gray5;
464+
465+ code {
466+ overflow: scroll;
467+ white-space: pre;
468+ padding: 0;
469+ }
455}
470}
456
471
457code, .code, .mono {
472code, .code, .mono {
templates/doc.html+1−1
@@ -17,7 +17,7 @@
17<!-- header -->
17<!-- header -->
18<!-- content -->
18<!-- content -->
19{% include "partials/navigation-docs.html" %}
19{% include "partials/navigation-docs.html" %}
20−<article class="mt4 mb6 full c4-12-lg measure-wide">
20+<article class="mt4 mb6 full c4-12-lg doc">
21 <!-- header -->
21 <!-- header -->
22 <h1>{{ page.title }}</h1>
22 <h1>{{ page.title }}</h1>
23 <!-- body -->
23 <!-- body -->
templates/grant_type/proposals.html+14−13
@@ -37,48 +37,49 @@
37 <h1>Proposals</h1>
37 <h1>Proposals</h1>
38 <p>Community members may submit proposals for a wide range of projects that contribute to Urbit. Past proposals have spanned a wide range of topics: </p>
38 <p>Community members may submit proposals for a wide range of projects that contribute to Urbit. Past proposals have spanned a wide range of topics: </p>
39 <ul class="list mb2">
39 <ul class="list mb2">
40− <li>Development projects, like <a class="bb" href="/grants/webrtc-gall-agent-and-external-app/" target="_blank">WebRTC integration</a></li>
40+ <li>Development projects, like <a class="bb" href="/grants/proposals/webrtc-gall-agent-and-external-app/" target="_blank">WebRTC integration</a></li>
41 <li>
41 <li>
42− <a class="bb" target="_blank" href="/grants/a-book-about-urbit/">
42+ <a class="bb" target="_blank" href="/grants/proposals/a-book-about-urbit/">
43 A book about Urbit
43 A book about Urbit
44 </a>
44 </a>
45 </li>
45 </li>
46 <li>
46 <li>
47 Creation of
47 Creation of
48− <a class="bb" target="_blank" href="/grants/urbit-explainer-video/">
48+ <a class="bb" target="_blank" href="/grants/proposals/urbit-explainer-video/">
49 video
49 video
50 </a>
50 </a>
51− <a class="bb" target="_blank" href="/grants/comprehensive-local-server-and-mum-explanation-video/">
51+ <a class="bb" target="_blank" href="/grants/proposals/comprehensive-local-server-and-mum-explanation-video/">
52 content
52 content
53 </a>
53 </a>
54 </li>
54 </li>
55 <li>
55 <li>
56− <a class="bb" target="_blank" href="/grants/urbit-event-series/">
56+ <a class="bb" target="_blank" href="/grants/proposals/urbit-event-series/">
57 Production of events
57 Production of events
58 </a>
58 </a>
59 </li>
59 </li>
60 <li>
60 <li>
61− <a class="bb" target="_blank" href="/grants/urbit-online-meetup/">
61+ <a class="bb" target="_blank" href="/grants/proposals/urbit-online-meetup/">
62 Hosting meetups
62 Hosting meetups
63 </a>
63 </a>
64 </li>
64 </li>
65 <li>
65 <li>
66− <a class="bb" target="_blank" href="/grants/graph-store-documentation-guide/">
66+ <a class="bb" target="_blank" href="/grants/proposals/graph-store-documentation-guide/">
67 Writing documentation
67 Writing documentation
68 </a>
68 </a>
69 </li>
69 </li>
70 <li>
70 <li>
71− <a class="bb" target="_blank" href="/grants/hoon-001-learner-efficiency-and-early-learner-resources/">
71+ <a class="bb" target="_blank" href="/grants/proposals/hoon-001-learner-efficiency-and-early-learner-resources/">
72 Educational materials
72 Educational materials
73 </a>
73 </a>
74 </li>
74 </li>
75 </ul>
75 </ul>
76
76
77− <p>Proposals are more likely to be approved if their relevance to the project is made clear, their scope is clearly defined, the proposer is qualified, and it's obvious that a lot of thought has gone into the idea.</p>
77+ <p>If you have an idea for how to improve Urbit, please read our <a class="bb" href="/grants/submit-proposal/">proposal submission guide</a>. Or, if you are ready, please feel free to: </p>
78−
78+ <div class="center">
79− <a class="b bb" href="https://airtable.com/shrCi54rEDxgSZr3z" target="_blank">
79+ <a class="b bb" href="https://airtable.com/shrCi54rEDxgSZr3z" target="_blank">
80− Propose a project
80+ Propose a Project
81− </a>
81+ </a>
82+ </div>
82
83
83 {% for page in term.pages %}
84 {% for page in term.pages %}
84 {% if not page.extra.canceled %}
85 {% if not page.extra.canceled %}
templates/grants/list.html+8−5
@@ -12,7 +12,10 @@
12{% endblock description %}
12{% endblock description %}
13
13
14{% block content %}
14{% block content %}
15−{% set posts = get_section(path="grants/_index.md") %}
15+{% set aposts = get_section(path="grants/apprenticeships/_index.md") %}
16+{% set bposts = get_section(path="grants/bounties//_index.md") %}
17+{% set pposts = get_section(path="grants/proposals//_index.md") %}
18+{% set posts = aposts.pages | concat(with=bposts.pages) | concat(with=pposts.pages) %}
16<!-- header -->
19<!-- header -->
17<nav class="mt4 full fourth-1-lg mb3 mb0-m mb0-l mb0-xl fixed-xl">
20<nav class="mt4 full fourth-1-lg mb3 mb0-m mb0-l mb0-xl fixed-xl">
18 <a class="gray3" href="/">Urbit</a>
21 <a class="gray3" href="/">Urbit</a>
@@ -62,17 +65,17 @@
62 <div class="grid12">
65 <div class="grid12">
63
66
64 <div class="c1-13 c1-6-md c1-5-lg flex items-stretch pv3">
67 <div class="c1-13 c1-6-md c1-5-lg flex items-stretch pv3">
65− {% set page = get_page(path="grants/bitcoin-full-node-provider-and-wallet.md") %}
68+ {% set page = get_page(path="grants/bounties/bitcoin-full-node-provider-and-wallet.md") %}
66 {{ macros::grant(page=page, mode="mini") }}
69 {{ macros::grant(page=page, mode="mini") }}
67 </div>
70 </div>
68
71
69 <div class="c1-13 c6-13-md c5-9-lg flex items-stretch pv3">
72 <div class="c1-13 c6-13-md c5-9-lg flex items-stretch pv3">
70− {% set page = get_page(path="grants/webrtc-gall-agent-and-external-app.md") %}
73+ {% set page = get_page(path="grants/proposals/webrtc-gall-agent-and-external-app.md") %}
71 {{ macros::grant(page=page, mode="mini") }}
74 {{ macros::grant(page=page, mode="mini") }}
72 </div>
75 </div>
73
76
74 <div class="c1-13 c1-13-md c9-13-lg flex items-stretch pv3">
77 <div class="c1-13 c1-13-md c9-13-lg flex items-stretch pv3">
75− {% set page = get_page(path="grants/urbian-a-customized-linux-distribution-for-urbit-appliances.md") %}
78+ {% set page = get_page(path="grants/proposals/urbian-a-customized-linux-distribution-for-urbit-appliances.md") %}
76 {{ macros::grant(page=page, mode="mini") }}
79 {{ macros::grant(page=page, mode="mini") }}
77 </div>
80 </div>
78
81
@@ -87,7 +90,7 @@
87 {% endfor %}
90 {% endfor %}
88 </ul>
91 </ul>
89
92
90− {% for page in posts.pages %}
93+ {% for page in posts | sort(attribute="date") | reverse %}
91 {% if not page.extra.canceled %}
94 {% if not page.extra.canceled %}
92 {{ macros::grant(page=page, classes="full c1-10-lg mv5")}}
95 {{ macros::grant(page=page, classes="full c1-10-lg mv5")}}
93 {% endif %}
96 {% endif %}
templates/sections/docs.html+1−1
@@ -17,7 +17,7 @@
17<!-- header -->
17<!-- header -->
18<!-- content -->
18<!-- content -->
19{% include "partials/navigation-docs.html" %}
19{% include "partials/navigation-docs.html" %}
20−<article class="mt4 mb6 full c4-12-lg measure-wide">
20+<article class="mt4 mb6 full c4-12-lg doc">
21 <!-- header -->
21 <!-- header -->
22 <h1>{{ section.title }}</h1>
22 <h1>{{ section.title }}</h1>
23 <!-- body -->
23 <!-- body -->
templates/sections/docs/chapters.html+1−1
@@ -17,7 +17,7 @@
17<!-- header -->
17<!-- header -->
18<!-- content -->
18<!-- content -->
19{% include "partials/navigation-docs.html" %}
19{% include "partials/navigation-docs.html" %}
20−<article class="mt4 mb6 full c4-12-lg measure-wide">
20+<article class="mt4 mb6 full c4-12-lg doc">
21<!-- header -->
21<!-- header -->
22<h1>{{ section.title }}</h1>
22<h1>{{ section.title }}</h1>
23<!-- body -->
23<!-- body -->