From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2790FC0012 for ; Mon, 13 Dec 2021 18:25:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 235AD60B21 for ; Mon, 13 Dec 2021 18:25:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuTBcg1i7H5R for ; Mon, 13 Dec 2021 18:25:48 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp3.osuosl.org (Postfix) with ESMTPS id C579D60B20 for ; Mon, 13 Dec 2021 18:25:47 +0000 (UTC) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BDIPimV032109 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 13 Dec 2021 13:25:45 -0500 Received: by mail-lf1-f49.google.com with SMTP id b1so32435625lfs.13 for ; Mon, 13 Dec 2021 10:25:45 -0800 (PST) X-Gm-Message-State: AOAM533OgnvttZFmVW1NriP8g4Z4vhh5b+wFADRULMPhQZyK4s3sNqU1 jYo1CEzDQ30zxUUnPjE9iPZqp3w84EOMNxZJeQE= X-Google-Smtp-Source: ABdhPJz/aqmgZZCfywdJlGvUiGG2Q63gfrXU6+biKpK8re7sVgSY+vNao0U/UoAna13xPOfMWmCP6cWrepCsyNEb1XY= X-Received: by 2002:a05:6512:1287:: with SMTP id u7mr76297lfs.226.1639419944354; Mon, 13 Dec 2021 10:25:44 -0800 (PST) MIME-Version: 1.0 From: Jeremy Date: Mon, 13 Dec 2021 10:25:33 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin development mailing list Content-Type: multipart/alternative; boundary="0000000000006bc8df05d30b3321" Subject: [bitcoin-dev] [Bitcoin Advent Calendar] Composability in Sapio Contracts X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2021 18:25:49 -0000 --0000000000006bc8df05d30b3321 Content-Type: text/plain; charset="UTF-8" Devs, Here's today's post: https://rubin.io/bitcoin/2021/12/13/advent-16/ It covers how you can use Sapio modules composably. This is an active area of research for the Sapio platform, so definitely welcome and appreciate ideas and feedback. One area I'm particularly happy with but also unhappy with is the "JSONSchema Type System". It is remarkably flexible, which is useful, but a better type system would be able to enforce guarantees more strongly. Of course, comparing to things like ERC-20, Eth interfaces aren't particularly binding (functions could do anything) so maybe it's OK. If you have thoughts on better ways to accomplish this, would love to think it through more deeply. I'm particularly excited about ways to introduce more formal correctness. Cheers, Jeremy p.s. -- feel free to send me any general feedback on the series out of band. There's a couple posts in the pipeline that are a bit less development focused like the earlier posts I excluded, and I could filter them if folks are feeling like it's too much information, but I'd bias towards posting the remaining pieces as they come for continuity. Let me know if you feel strongly about a couple posts that might be a topical reach for this list. -- @JeremyRubin --0000000000006bc8df05d30b3321 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Devs,

Here's to= day's post:=C2=A0https://rubin.io/bitcoin/2021/12/13/advent-16/

It covers how= you can use Sapio modules composably. This is an active area of research f= or the Sapio platform, so definitely welcome and appreciate ideas and feedb= ack.

One area I'm particularly happy with but also unhappy with i= s the "JSONSchema Type System". It is remarkably flexible, which = is useful, but a better type system would be able to enforce guarantees mor= e strongly. Of course, comparing to things like ERC-20, Eth interfaces aren= 't particularly binding (functions could do anything) so maybe it's= OK. If you have thoughts on better ways to accomplish this, would love to = think it through more deeply. I'm particularly excited about ways to in= troduce more formal correctness.

=
Cheers,

Jeremy

p.s. -- f= eel free to send me any general feedback on the series out of=C2=A0band. Th= ere's a couple posts in the pipeline that are a bit less development fo= cused like the earlier posts I excluded, and I could filter them if folks a= re feeling like it's too much information, but I'd bias towards pos= ting the remaining pieces as they come for continuity. Let me know if you f= eel strongly about a couple posts that might be a topical reach for this li= st.

--0000000000006bc8df05d30b3321--