rvagg

Work in progress, I'll write this up properly when I'm done.

Almost all credit goes to @maxogden for putting me on to this and pointing me in the right direction for each of these items.

Prerequisites:

• Raspberry Pi
• Kindle Paperwhite freed from its locked down state (jailbroken) http://www.mobileread.com/forums/showthread.php?t=198446
  • You have to downgrade your Kindle to 5.3.1 to install the current jailbreak; that's just a matter of getting the old version image, putting it on your Kindle via USB and telling it to install "upgrade". Then you put in the Jailbreak files, load the ebook and break.
• Your kindle will be quick to detect an upgrade is available so it'll want to upgrade soon afterwards but the jailbreak will last but you have to reinstall the developer certificates so it's a bit of a pain but doable. Find all the instructions on the mobileread.com forums and wiki.

rvagg

#!/bin/bash

# Note your /usr/local will need to be writable by the user running it,
# alternatively run it with `sudo`

hasxz=$(which xzcat)
os=$(uname | tr '[A-Z]' '[a-z]')
arch=$(uname -m)
targetdir="/usr/local/"
domain=nodejs.org

rvagg

Lassie & IPLD

https://github.com/filecoin-project/lassie

Lassie what?

Lassie is:

rvagg

### Generated automatically from Makefile.org by Configure.

##
## Makefile for OpenSSL
##

VERSION=1.0.2
MAJOR=1
MINOR=0.2
SHLIB_VERSION_NUMBER=1.0.0

rvagg

package main

import (
	"bytes"
	"context"
	"fmt"
	"io"
	"os"

	"github.com/ipfs/go-cid"

rvagg

{"cid":"bafybeihux5wmr7tia4eimuodo5hapw6cxl2qbjfnj4nd6lugrw5jylbjsy","event":"connect","eventDetails":null,"eventTime":"2022-07-20T12:17:13.878442835Z","instanceId":"autoretrieve-unnamed","phase":"query","phaseStartTime":"2022-07-20T12:17:12.967932646Z","retrievalId":"065842cf-1b75-435b-8396-9a11c5d3b283","storageProviderId":"12D3KooWRnVTEA1jScyYsCwBxi1hYvxvoDDfPyLkow3eyX2B92c3"}
{"cid":"bafkreicpjzh2fqcyaws4cqysuary46skccfdv3f63d3rdwpy46ob4bsbk4","event":"connect","eventDetails":null,"eventTime":"2022-07-20T12:17:14.098088619Z","instanceId":"autoretrieve-unnamed","phase":"query","phaseStartTime":"2022-07-20T12:17:14.097663068Z","retrievalId":"37903ab7-a8f4-4398-837d-601ec57e30f3","storageProviderId":"12D3KooWRnVTEA1jScyYsCwBxi1hYvxvoDDfPyLkow3eyX2B92c3"}
{"cid":"bafybeiaphugi3dulcnxchx6jm7gx57z4nnkdht32dxagurxo4dulmxwqo4","event":"connect","eventDetails":null,"eventTime":"2022-07-20T12:17:14.315414746Z","instanceId":"autoretrieve-unnamed","phase":"query","phaseStartTime":"2022-07-20T12:17:13.518404076Z","ret

rvagg

This post builds on the discussion multiformats/multicodec#203 and is posted here because it might be a bit too long and in-the-weeds and I doubt many will actually read this all anyway! But I'd like this as a record of an ongiong broader disucssion about these topics.

---

Working through the process of mapping blockchain block formats to IPLD has made me see this question slightly differently. First it was getting the full bitcoin chain format working, including the awkward segwit hacks, and now it's working with @i-norden through getting the full ethereum format mapped to IPLD (e.g.).

The primary goal we're trying to achieve with IPLD codec codes here (via CIDs usually) is describing what glasses we put on to see the data. We want to get something into the data model in memory from the raw binary we've been handed.

An obvious example of having different glasses would be these CIDs:

rvagg

82                                                # array(2)
  9f                                              #   array(Infinity)
    82                                            #     array(2)
      52                                          #       bytes(18)
        2f6261636b757064732f6c6f672f68656164      #         "/backupds/log/head"
      58 43                                       #       bytes(67)
        313632373939333934302e6c6f672e63626f723b  #         "1627993940.log.cbor;"
        61613539656265302d613938382d343938302d62  #         "aa59ebe0-a988-4980-b"
        6366332d3739613134346566623962313b313632  #         "cf3-79a144efb9b1;162"
        37393933393430                            #         "7993940"

rvagg

Continuing on from multiformats/js-multiformats#35 (comment), because I don't want to derail that but I'd like to seed more thinking about how we can move toward better high-level IPLD abstractions.

There are currently a few different visions about this topic, but mostly I think it's pretty grey because we need to experiment with it more to figure out what actually makes sense. I think some of our current core differences are around what to do with the block boundary. I'd like us to try and erase the block boundary more at the user-facing end (not entirely, it's an abstraction that has to leak to some degree because there are costs to pretending it doesn't exist). go-ipld-prime is pushing forward to a model that I think we can somewhat mirror in JavaScript, with some major differences - primarily in that we have the async boundary to deal with, and we can use plain JavaScript objects to represent complex things (they have to either pre-define their object shapes or us

rvagg

{
  "logFormatVersion": 1,
  "jobId": "f7c77a9c-472c-4a0e-b80b-b776c42e1fad",
  "status": "Accepted",
  "statusSummary": "Ready for distribution",
  "statusCode": 0,
  "archiveFilename": "node-v14.0.0-nightly20200122c68fa207d7.pkg",
  "uploadDate": "2020-01-22T04:18:58Z",
  "sha256": "da3f7b4293a98afa17753a376e9b8240940b859eef305cdeeb874a1094097e78",
  "ticketContents": [