command composability

[aza]

EXPLORATION AND IDEA FUZZING

This pseudo spec is an exploration of @tonygentilcore's insight that /album #foo can create an album container whose contents are back by channel #foo. It's a vein that goes deep. This is meant to be interpreted as a sketch/brainstorm .

Background: #20, #17

In particular, this explores what happens when (1) you can create a container that embeds (part) of another channel, and (2) you can compose commands.

/channel

• /channel #channel:messageA-messageB creates a container which embeds part of one channel in another.
• /channel #channel:messageA creates a container which embeds the specified message
  • maybe /message messageA is sugar for /channel #thischannel:messageA

Syntax is super strawman and is [|....]. Maybe we can borrow from CSS selectors? Not sure what an interface for selecting a message, or message range would look like.

It seems that being able to reference messages and (parts) of channels is a fundamental building block of many of our actions.

Rechat, for example, can be though of as a styled /channel #fromchannel:message followed by an appropriate /caption.

composability

A natural extension of commands is to let them be composable. Why not plug the output of one into the input of another?

• /fullscreen /playlist #juanxa/music/danke to make a fullscreen music player (see below)
• /pdf( /article #aza/book/chapter1, /article #aza/book/chapter2 ) to create a pdf of the article form of the subchannels of #aza/book (see #31)
• /h1 /channel #channel:0 to have render out the last message in a channel as a title (say for putting in a pocket). Prepending by /fullscreen creates a TV mode

With composability, it makes it fast to define new containers/behaviors... without leaving the iOS client!

For example (very pseudo):

• /rechat := /indent( /channel #channel:message ) /caption rechat from #fromchannel
• /quote := /p $text /indent( /channel #channel:messageA-messageB )
• /todo $text := /h3( /checkbox $text ) creates a todo item with a checkbox styled biggish
• /expense-report := /h1( Expenses ) /h2 =sum( /channel #other/expenses )

Now imagine this:

• Given input elements like /slider{min:0, max:100, id:'price'}, /slider{min:0, max:10: id:'order-size'}
• You can now make interactive spreadsheet-like behavior:
  • /h2 Total: =( /message[id:"price"] * /message[id:"order-size"] )

Uses calculator (#29)

You can imagine how this can be extended to creating buttons/polls/voting:

• /h2 Do you like #bb? /container( /button{label:"Yes"} /button{labe:="Extra Yes"} )

// SUPER PSEUDO
var msg = new Message('/h2 Do you like #bb?')
msg.add('/button{label="Yes"} /button{label="Extra Yes"}')
msg.find('.button').on('click', function( evt ){ ... })
client.channel.post( msg )

/fullscreen

• Causes a message to be displayed as fullscreen
• Needs some interface to see the backing channel (say via long-hold action sheet)
• Can be used to turn a channel into a more app-like experience: /fullscreen /album #adam/knives posted to the pocket of #adam/knives.
• Can also be used to create channel redirects. Say I have #foo and want to instead have it point to #bar. I would then post /fullscreen /channel #bar
  • If there was already content in #foo, maybe I'd make #foo read only and then put /h2 Please use #bar, /channel #bar:0-5 to have it show the last five messages of #bar.
• Want to have your webpage as a subchannel? Post this in that subchannel /fullscreen /webreader http://topr.ytmnd.com/

maybe /app? what if there are multiple messages in the same channel with /fullscreen?

[aza]

Quoting @mtkurlowski:

• We will need to exercise caution given that these containers take content created by others (and content that may not be intended to leave the original location).
• We want to encourage the feeling that you can be public within your extended local and maintain a sense privacy through obscuration.
• Since everything is a link, having your content spread beyond your extended local in an automated fashion could break that obscuration.
• A simple solution to the above is to implement a request based permissions model. In order to use content not owned by you as a source for a container, a request is sent to the owner '@m requests access to media from this channel' and it is accepted or rejected.
• This sort of transparency will promote polite and respectful behavior.
• Preference to always allow scraping or never allow scraping from channels you own.

[tonygentilcore]

Love this. Seems super powerful.

• I don't have a concrete proposal yet, but somehow the messageA:messageB ranges seem like they could also be a useful primitive for setting the /wall ranges.
• Agree w/ @mtkurlowski's point about sharing. I think it just means our permission/discovery model needs to be robust enough to handle that. The chat request sounds like the right default for those privacy-through-obscurity channels. If a channel is indexable, presumably that means the author has pre-consented.
• My one reservation here is that this starts to fall down the slippery slope of inventing a DSL -- which usually doesn't go well. I wonder whether CSS selectors are powerful enough to express all the things we need. If so, maybe we have an other.css to go with our other.js! That would be really cool, because the other day I realized that the format of our textual message (e.g. <!123>, <#123>) is our equivalent of HTML.

[tonygentilcore]

This issue was moved to other-xyz/time-cone#80