belisarius222

I just realized we should be able to delete gall's outstanding request queue entirely -- but we probably don't want to do that now, since the migration might be hairy
we could do this now because pokes and watches can never share the same flow
so there's no need for gall to maintain state to disambiguate them
we would need to collapse the foreign sending down to a single-step move, instead of a stack of two wires
so instead of gall passing a move to itself, then passing a move to ames,
gall would need to see the %watch, %leave, or %poke come out of the agent, then fire it off to ames with a wire that says whether it was a subscription or poke
a subscription wire would also need to say which foreign ship, agent, and path we're subscribing to (or unsubscribing from), and contain the subscription nonce
a poke wire would just need the foreign ship and wire the agent set, I believe
I'm not sure how we would migrate to this, especially for the poke case -- for subscriptions, we could potentially kill all existing s

belisarius222

::   :-  :*  title+"urbit-flavored markdown docs"
::           author+"ted blackman"
::           date+~2017.8.25
::       ==
::  
;>

# udon: urbit-flavored markdown

## overview

belisarius222

Ames Push-Based Reconnect

As it stands, Ames re-sends packets to an offline peer forever, every two minutes. For a ship with, say, 2400 offline subscribers to five chat channels, this adds up to a hundred packets being sent per second to ships that aren't there. A lot of those packets will also go through a relay before being hurled into the void, forcing the relay to do essentially meaningless work.

This is a fair amount of wasted CPU, bandwidth, and disk usage (every retry is a new Arvo event on the sender, which must be written to disk). To make it worse, the retry rate trades off against reconnect latency. If my ship comes back online after a few minutes of downtime, it will take on average one minute -- half the retry interval -- before I hear retried packets from my peers. Lowering the retry interval to lessen the reconnect time would increase the bunk packet rate, which increases systemic load on the network.

A couple years ago, ~wicdev-wisryt proposed switching Ames to use push-based recon

belisarius222

+$  note
  $%
  ::  %ames
      [%sift ships=(list ship)]
      [%spew veb=(list verb)]
  ::  %behn
      [%wait date=@da]
      [%rest date=@da] 
  ::  %clay
      ::  TODO: %warp, %info, %park, %merg

belisarius222

def gray(n):
    if n == 1:
        return ["0", "1"]
    originals = gray(n - 1)
    prefixedOriginals = ["0" + d for d in originals]
    reflected = list(reversed(originals))
    prefixedReflected = ["1" + d for d in reflected]
    return prefixedOriginals + prefixedReflected

belisarius222

|%
::  $plan: ford build, at the current beak
::
+$  plan
  $%  [%'/.' data=vase]
      [%'//' =spur]  ::  produces !>(*(unit [mark contents]))
      [%'/*' =hoon]
      [%'/=' face=@tas value=plan]
      [%'/:' head=plan tail=plan]
      [%'/>' with=plan rest=plan]

belisarius222

A scry packet is either a request packet, sent from requester to host, or
a response packet, sent from host to requester.
Some request packets and all response packets are signed.
Paths are encoded as null-terminated ASCII text, except for the host ship,
which is encoded the same way as in Ames,
so as not to slow down relaying with string parsing.

Scry packets are not responsible for peer discovery and
therefore do not include an "origin" field like Ames packets.

belisarius222

[8.909.898.678.765.747.192.222.496.419.433 [1.547.502.848 122.585.133.865.456.070.768.289.138] [17.826.304 [727.297.206 0 0] 3.636.038.703 [1.471.624.404 [46.901.714 [98.508.064.685.512.714.131.431.889.268.921.467.136 [377.881.856 [38.863.872 0 0] 208.369.818.243.882.581.233.561.692.627.075.007.488 0 460.032 [163.132.979.714.802.956.572.376.767.866.019.709.696 0 0] 207.507.362.372.271.488.339.077.218.035.923.222.784 0 0] 273.039.027 0 0] 271.646.908.320.357.328.305.654.769.512.108.916.992 [2.437.088.256 [63.236.944.151.159.559.491.195.372.633.782.419.712 [2.122.444.651 [12.190.720 0 0] 0] 6.554.368 [2.865.038.758 0 0] 2.642.114.485 0 0] 2.505.935.919 [322.028.769.875.806.775.348.013.658.829.832.061.184 [2.381.819.040 0 2.359.899.348 0 0] 2.099.883.190 0 0] 2.278.978.205 0 0] 9.372.066 [3.178.299.826 [1.742.733.824 [818.291.878 0 0] 851.970.230 0 0] 0] 61.283 [467.890.845 [210.535.763.981.882.411.786.672.100.501.168.259.328 [8.061.184 0 0] 0] 200.055.289.992.422.841.599.103.354.385.164.337.408 0 0] 933.036.847

belisarius222

It's useful to have standard names for types, but it's also useful to have standard names for variables. In Hoon, we strive for unambigious and fast pronounceability. If you read a Hoon program to me over the phone, I should be able to dictate it perfectly without wondering how something is spelled. While this goal is probably not completely achievable, we can get a lot closer than we are right now. I propose a scheme for getting close to this.

In many programming languages, single-letter variable names are common. In Hoon, these are called "ultra-lapidary style". These usually satisfy Hoon's pronunciation requirement, but they do not map naturally onto meaningful concepts except when the number of variables is very low. For a comparator function, taking in 'a' and 'b' is fine. But for arguments whose meaning is more semantic than positional, which is most of the time, a name should have some mnemonic connection to the value it signifies.

The natural way to do this is a full word, which should be c

belisarius222

For those of you at home, I wanted to include some instructions for S3 support.

S3 support lets you store credentials for your S3 object storage buckets on your Urbit ship; once you have done so, you will get additional functionality for uploading your own media within Chat and Groups (for avatars).

It’s for power users at the moment — it requires some technical setup, but we hope to surface some UI for it as we go.

You will need to get an S3 bucket set up. If you’re using AWS, it will have to support signature v2, not v4. We found DigitalOcean worked well. The bucket has to be publicly readable; allow CORS from * origins, and allow * headers. Your provider should have details on setting access permissions and CORS.

Once you have gotten your bucket setup, poke the s3-store on your ship with your details. You can do this in Dojo or in web Dojo, it will work however.