06:18 <lain`> does the sandcats tunnel service terminate ssl at the sandcat servers or is the encryption end-to-end? (is the ssl terminated at the server running sandstorm)

06:41 <lain`> sorry, i misunderstood the docs. I thought it was a tunnel but i guess it's just dns

07:12 <ocdtrekkie> yeah, it's just zero config ddyns + let's encrypt. I expect it'd be possible to do something like Cloudflare Access or something to put a tunnel in front of Sandstorm with your own domain, but I haven't tested it yet.

19:22 <fr33domlover> isd: Hi :) I haven't touched Haskell stuff but now starting a year of NLNet-funded work, much of it on Vervis, so I guess I'm back in business :P

19:22 <fr33domlover> One of the challenges I've noticed about CapnProto (at least the Haskell version) is that it's very verbose, so writing an app with an actor architecture where everything is CapnProto might be difficult, e.g. compared to Spritely. Do you see potential for some sort of DSLish/concise syntax that could make actor programming be convenient? Or would

19:22 <fr33domlover> that likely require a dynamic/specialized programming language?

19:24 <isd> It's actually *worse* in other languages; most implementations don't generate "normal" datatypes, so you have to use getters and setters... :/

19:24 <isd> I'm also not thrilled with how verbose things are, and am interested in improving the situation.

19:25 <isd> It might help to identify specific constructs and brainstorm ways to make them better.

19:26 <isd> I actually have toyed with the idea of basically extending the schema language into a proper programming language :P

19:27 <isd> I don't think dynamic is really the issue. I wrote a whole blog post about my gripes with the schema language a ways back: https://zenhack.net/2019/06/25/a-critique-of-the-capnproto-schema-language.html

19:27 <isd> I think I've gone back on my position wrt. multiple inheritance.

19:27 <isd> But most of that still stands.

19:27 <isd> There may also be some tips in there you can use to avoid features that make things more verbose, but the situation isn't great.

19:34 <isd> fr33domlover: https://codeberg.org/zenhack/haskell-capnp/issues/89

19:39 <fr33domlover> Thank you for shedding light on the situation! My next todo-item is to refactor my current ActivityPub-based code into an actor-style architecture, looking to see if there's any relevant actor package to use, or make a quick custom one. I gave this task ~5 weeks :P basically trying to make a foundation for smooth development but still using

19:39 <fr33domlover> kind-of-weak AP-based actors. NLNet asked me to reduce the size of the OCAP experiment (to prioritize progress with the AP related tooling) but it's still in the plans and when I get to those tasks I'll play with the capnp library and try to find ideas for improving the verbosity situation :)

19:40 <isd> I feel like the names for parameter & result structs are one of the worst things.

19:41 <isd> ...would be a lot easier if haskell supported elm-style records

19:44 <isd> Note that giving those their own names manually in the schema language can help alot, e.g.... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/985c9322bec38da2bbc1bc0a39c4d56294bc7f77>)

19:45 <isd> Then the type & data constructor just ends up being named `BarRequest` instead of `Foo'bar'params`, which can be really annoying of the interface & method names are longer.

19:46 <isd> I feel like there's also room to define some specific types that the schema compiler/library "knows about" e.g.... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/05d6b721b6c7aaa81f243d6081938e358b1c37d6>)

20:21 <fr33domlover> I'm grateful for the foundation you've implemented, now the convenience/interface stuff is hopefully just the cherry on top

20:21 <isd> I hope it's more design work than implementation

20:24 <isd> I might post a lot of comments in the near future to that issue; I'm realizing I've had a lot of rough thoughts in the past that are maybe worth revisiting.