Aaron Craelius aaronc

Proposal for Idris Package Support to Prevent "Dependency Hell"

I know there has been some discussion around what type of package manager to use for Idris. I know some people have proposed Nix and I've started checking it out myself. This proposal is really aimed just at low-level support that would help any package manager (including Nix) prevent the soul-sucking, time waster that is dependency hell.

It seems that most languages don't address this until it is too late and then need extraordinary community efforts to deal with it (ex. Haskell with Cabal sandboxes and Stack or Java with Project Jigsaw). Only one platform I know of (NodeJS with NPM) got it right from the start by allowing a nested dependency graph. With some careful planning and a few pieces of language-level support I think Idris can do this too.

I think what is most essential in preventing dependency hell is being able to reference two different dependencies that declare a module with the same name. I've done a check with Idris in it's c

Codec

It seems like one of the core issues with client side support is an implementation of Amino in some language other than golang.

A couple work-arounds that occur to me are:

Create a REST server endpoint that decodes JSON with Amino and re-encodes it in binary Amino.
Compile Amino using gopherjs. I have tried this and it appears to be possible, although I haven't tested the generated JS. This is still a work-around, however, because to natively use from JS you would still need to emit JS, have the gopherjs Amino build decode the JS then re-encode it into binary (because the gopherjs compiled go structs aren't native JS structs). For iOS & Android, it may be possible to do the same with gomobile.

Long term solutions:

Implementing Amino in JS and other frontend languages. If one were going to implement Amino for just one more language I would suggest Kotlin specifically aims to be multiplatform and comp

Fee delegation

The delegation module also allows for fee delegation via some changes to the AnteHandler and StdTx. The behavior is similar to that described above for Msg delegations except using the interface FeeAllowance instead of Capability:

// FeeAllowance defines a permission for one account to use another account's balance
// to pay fees

Hackatom Berlin

Regen Network, and our compatriots from TruStory, IOV, Althea and Wallet Connect combined forces to become Team Gaians for the Berlin HackAtom. This blog will review what we created and what it can be used for.

Our team focused on hacking towards a clear use case: user friendly participation in smart contracts about ecological health. In order to create usable functionality for this the team had to overcome some key challenges: create a smart contracting framework for the Cosmos SDK and improved key management.

And that is exactly what was accomplished. In 36 hours, the team pulled together an incredibly powerful and flexible, smart contracting module using WebAssembly (Wasm) and key management modules that interact to create platform that is more powerful and robust than Ethereum, and built in the Cosmos SDK, making interoperability with other chains easy.

Let’s walk through the functionality that was built using the use-case we considered - a simple three-party contract for Regen Netw

Keybase proof

I hereby claim:

I am aaronc on github.
I am aaroncr (https://keybase.io/aaroncr) on keybase.
I have a public key ASCD3PDnlWKAdlNdbqIhut64-s5Bqh_BOMbdEFSNobkTzwo

To claim this, I am signing this object:

Motivation

Our current upgrade module uses the gov module to trigger a planned upgrade, this has a few potential downsides:

if a hot-fix release is needed, the network needs to wait for the full voting window
if validators need to postpone an upgrade after the governance vote due to some issues found in testing, they can't do that
no built-in way to abort an upgrade in case the upgrade handler fails

Proposal

Motivation

Proposal

proto3 Canonical Encoding Rules (CER)

This defines a set of encoding rules for Protocol Buffers 3 (proto3) for serializing messages deterministically such that the serialized form is suitable for signing and encoding in cryptographic attestations (ex. Merkle trees). Similar to ASN.1 and Cap'n Proto, a set of "canonical encoding rules" (CER) is used to define a canonical encoding where the basic proto3 specification does not do so. In this sense, the default protocol buffers specification provides a set of "basic encoding rules" which are not deterministic, and we extend that specification to support deterministic encoding for cryptographic use cases.

	// ----
	// libsass (v3.3.2)
	// ----

	@import "jeet/index";
	@import "bourbon/bourbon";
	@import "neat/neat";
	@import "susy";

	{
	"binaries": {
	"darwin/amd64": "https://github.com/regen-network/regen-ledger/releases/download/v0.5.0/regen-ledger-v0.5.0-darwin-amd64.tar.xz?checksum=sha256:1dc22afb1ae71c11971cac7367d9f525e66ef1b7e7d8c039b6acd28de45a452a",
	"linux/amd64": "https://github.com/regen-network/regen-ledger/releases/download/v0.5.0/regen-ledger-v0.5.0-linux-amd64.tar.xz?checksum=sha256:9e8a5b837fe94190ffa415304d2004fee74bc6315e4417840b13053237da3e19"
	}
	}