Closed tiller-tolbus closed 3 weeks ago
Maybe if it passes all of these tests, it could be a primitive shipped as standard:
I would expect a high degree of overlap between what can be classified as "primitive" and what products will want to support. Prior art suggests that proprietary products may extend the feature-set of existing primitives (ex. Excel vs. Numbers, Sublime Text vs. Notepad).
I think for framing it might help to start with some obvious examples of needed primitives and work our way backwards towards what makes them that way:
|hi
)What makes the above obviously primitives, IMO, is that a developer having to roll their own of one of the above would feel ridiculous and unnecessary, and would make them feel inspired to create their own application rather than extending a larger one.
Some more arguable cases that would qualify by the above argument:
This has a pretty high overlap with what I already see as the primitive use-cases of Sky, but I think it stands to reason. The primitives we want are the things that developers want to already see included before they begin writing their own specific tools.
We should think carefully about the primitives that will enable data composability. Important to design primitives that will allow an ecosystem of apps to thrive and inter-communicate, rather than building the whole ecosystem ourselves.
%pals is an example, how could %pals be better? Groups of people are a really important primitive -- Tlon at one point wanted their software to serve such a purpose.
how could %pals be better?
Pals is an example of an Access Control Group with a negotiation/notification step, which is certainly in scope. The plan is to have multiple access control groups and to use them as primitives for various things. There's no one canonical friends list, but there can be one group that the user treats as their friends list.
Here's what we will work on in the near term:
We expect the features that we want out of a future Sky to evolve from a combination of primitive types, conversions, channels, and overlays.
These are the primitive data structures that we will support in the services we build.
%circle
(friends list, ACL)%message
(text message)%text
(arbitrary text to apply to conversions, see below)%path
and %pail
(arbitrary content for embedding and previewing)These are the primitive ways that we handle data automatically through the system in order to process it into something that the user can make better use of.
syntax: con/input/role/output
Note: Primitive types and conversions apply to a much broader surface area, above are examples that we can make immediate use of.
These are services that work on the basic %message
type and others, and determine who is able to see a given message. These protocols should be able to flow into one another.
Users should be able to create a datum related to some path and broadcast it to a select channel.
The above can be considered "ingredients" for composing desirable features. Ex. a global feed is a gossip channel over messages and previews; comments and reactions on the global feed are overlays. A filesystem can be composed out of tags and redirects and applied to any data in the tree. A private blog is a text document that converts to HTML through Markdown and is shared with a Circle as an ACL.
Josh says that the new token will be the native unit of account for all economic activity on Urbit. As shrubbery aims to be the future of Urbit, it makes sense to me that there should be primitives that handle sending, receiving, storing this token and converting it to other currencies. Since the value that accrues to this token will reflect the value of the economic activity happening on Urbit, the best way to drive value to this token and the ecosystem should be to support economic activity in it as a primitive.
Yeah, financial plumbing should definitely be a shrub primitive at some point but the token falls well out of our ~6-month timeline. I thought about throwing a Base USDC shrub in there as a trial run but I'm not sure whether or not crypto rails are the kind of thing where third-party devs would all want their own particular implementation of it. Would be nice to have paid subscriptions to other ships' namespaces in 6 months but we arguably need the token before it falls under the "primitives" remit.
Comment from @liam-fitzgerald is that most of the combinatorics we actually want in our primitives discussion can be handled without overlays and by doing the combinations in the UI or the /con
file. This does require the use of what Liam is calling "shadow children", which are paths that are outside of the explicit constraints of the concrete shrub, which can contain arbitrary metadata like comments or reactions.
Great discussion here; this issue has fulfilled its role.
What are the primitive services that we want to support? What is our attitude towards declaring something as a primitive and including it in the base software distribution? What is the overlap with our existing work?
Discuss ideas here and we will narrow down during a coming workshop.