Skip to content

Instantly share code, notes, and snippets.

{
"type": "module",
"moduleType": "javascript/auto",
"layer": null,
"size": 1346,
"sizes": {
"javascript": 1346
},
"built": false,
"codeGenerated": false,
@yusefnapora
yusefnapora / gitconfig
Created June 30, 2021 17:02
git aliases to checkout the head branch of a repo
[alias]
upstream-name = !git remote | egrep -o '(upstream|origin)' | tail -1
head-branch = !basename $(git symbolic-ref refs/remotes/$(git upstream-name)/HEAD)
cm = !git checkout $(git head-branch)
@yusefnapora
yusefnapora / multiselect-2-sandbox.proto
Last active September 13, 2019 12:44
early thoughts on data types for multiselect 2
syntax = "proto2";
// The initiator chooses whether to set up a multiplexed connection, or a "one
// off" stream for a single protocol. Single stream connections may be useful
// for bootstraping a hole-punching protocol through a relay and other things
// where you just want to get "in and out" of a connection asap.
enum ConnectionType {
MULTIPLEXED = 1;
SINGLE_STREAM = 2;
}
@yusefnapora
yusefnapora / libp2p.md
Created July 29, 2019 21:00
EthBerlinZwei libp2p resources

libp2p

libp2p is a modular framework and protocol suite for developing peer-to-peer applications. Originally part of the IPFS project, libp2p has evolved to meet the needs of a growing community of developers and users.

There are many implementations of libp2p, with go-libp2p being the oldest and most "feature complete". Javascripters can use

@yusefnapora
yusefnapora / mediachain-next-api.md
Created August 26, 2016 19:33
high-level api design notes for mediachain phase 2 design

mediachain.next api notes

Everything here is in flux and subject to change; this is just a sketch. The idea is to give an overview of the high-level api surface of an "online" node, that is, one that actively contributes to the network and is expected to remain connected to the network.

All the code examples below are in javascript, with flow-style annotations for return types.

Peer ids & local state

A peer has a unique id, which is the hash of their public key. They may also have a collection of certificates, signed by moderators of the namespaces they're authorized to participate in.

The peer-local state includes the peer's id, certificate store, private key, etc. It also includes the index of connected peers, which allows us to route operations to peers with the correct roles.

$ virtualenv venv
$ source venv/bin/activate
(venv) $ pip install -U pip
(venv) $ pip install mediachain-client
(venv) $ mediachain get QmVwwiMVDH7umVSd3vdbwGS3WmFX2axhJCTpbfU4LMPcE8
{
"metaSource": {
"@link": "Qmcbo67Ycv6rCREhQYoYeGJzgAJiCZDfyEdtHqdbmTsv6T"
},
"meta": {

Keybase proof

I hereby claim:

  • I am yusefnapora on github.
  • I am yusef (https://keybase.io/yusef) on keybase.
  • I have a public key ASDpxm7pgDUDKs8tbHQ4jFHkm-fb4YaPhy0bWASLQk2WBwo

To claim this, I am signing this object:

@yusefnapora
yusefnapora / setup.scala
Last active June 8, 2016 18:38
setup local dynamo for mediachain
import com.amazonaws.auth.BasicAWSCredentials
val awscreds = new BasicAWSCredentials("", "")
import com.amazonaws.services.dynamodbv2.AmazonDynamoDBClient
val dynamo = new AmazonDynamoDBClient(awscreds).withEndpoint("http://localhost:8000").asInstanceOf[AmazonDynamoDBClient]
import scala.collection.JavaConversions._
import com.amazonaws.services.dynamodbv2.model._
val baseTable = "Mediachain"
@yusefnapora
yusefnapora / applicative-future-cats.scala
Created May 13, 2016 14:41
Applicative instance for scala Future using cats
object Foo {
// based on this scalaz version: https://gist.github.com/Fristi/e7139a89e2c66d455e97
implicit def applicativeFuture(implicit executionContext: ExecutionContext)
= new Applicative[Future] {
override def pure[A](x: A): Future[A] = Future.successful(x)
override def ap[A, B](ff: Future[(A) => B])(fa: Future[A]): Future[B] =
ff.flatMap(fa.map(_))
@yusefnapora
yusefnapora / transactor-interface-draft.markdown
Last active April 21, 2016 21:38
transactor interface notes

Transactor interfaces

The Transactor peer nodes are responsible for writing data to the system and ensuring consistency.

Transactors have two main client-facing interfaces:

  • writing data to persistent storage (e.g. IPFS) on behalf of clients
  • informing clients of changes to the Journal when updates are made