16:36 <ill_logic> Is this Matrix / ActivityPub stuff similar to how IPFS would be implemented? Sort of as an external service that the applications could call upon?

16:36 <ill_logic> And could good old fashioned Torrent work the same way?

16:37 <ill_logic> It occurred to me thinking about the OSM stuff - it would be really killer if lots of grains were sharing a torrent or IPFS of the map data.

16:38 <ill_logic> Otherwise I'd been thinking about hosting it myself. I don't want to rely on these oddball sites that the guides point to.

16:38 <ill_logic> And I don't think those sites would appreciate it either.

16:38 <ill_logic> Same with Kiwix, though they have torrents for all their data already, so we'd just be playing the existing game. Which is good.

16:39 <ill_logic> "...killer if lots of grains were sharing a torrent or IPFS of the map data" I should say, Sandstorm instances, not grains. Sharing with each other.

16:59 <JacobWeisz[m]> I think it'd be interesting for large data storage if you could share certain common data with all users of an app on an instance, like if there was an OSM data bundle so each user didn't need their own full copy.

17:00 <ill_logic> Hmm. Then you might end up talking about something like a shared database.

17:00 <ill_logic> Which may or may not start to tear down Sandstorm's model.

17:01 <ill_logic> Because what I was talking about with IPFS was the data files, which yes, certainly should be shared among grains, especially given that it's ID'd by a hash.

17:01 <ill_logic> However to use that data, the first thing you do is import it into a database.

17:01 <abliss1> i think a davros-backed storage grain with something like ian's magic filesystem might work.

17:04 <abliss1> though i don't see why you couldn't wrap sql or something in capnp if you really wanted 2 grains to share a relational db.

17:05 <abliss1> typically the relational db contains exactly the data that a grain is meant to isolate.

17:07 <ill_logic> It could be read-only for that matter. Just that one grain would have to do the initialization.

17:07 <ill_logic> With writes, obviously.

23:31 <abliss> isd: when matrix connects to the powerbox proxy, i don't get any popups, but server.go reports "Failed to read HTTP request from spoofed TLS connection local error: tls: bad record MAC". Any idea what that could be about?

23:36 <isd> abliss: Did you rig up the ca correctly?

23:36 <abliss> not sure-- but hangon, it looks like the script didn't get into my browser correctly, fixing that first

23:45 <abliss> weird... i got the websocket working, and just tried to do a `curl --insecure https://example.com` against the proxy from within the grain. I got a powerbox request (yay!) but after granting it, i get another powerbox request for `http://http-bridge` ?

23:46 <abliss> maybe thats an artifact of launching the request from a curl commandline in nsenter, instead of the actual grain (somehow)?

23:49 <abliss> I get the same 'bad record MAC' error when using curl's `--cacert` option (curl -v reports `successfully set certificate verify locations` and lists the path to the .pem, so I think I did it right)

23:50 <isd> hm, that looks like the powerbox proxy is trying to use itself as a proxy to connect to the bridge. Are you setting the http_proxy and related variables before launching the powerbox server?

23:50 <isd> Maybe that should be pointed out more explicitly in the docs -- you want the powerbox proxy to still be using the bridge as its own proxy

23:51 <abliss> oops, yes, good point!

23:52 <abliss> (aside: this is revealing a bad UX problem when a grain attempts to DOS with neverending powerbox requests. the powerbox is modal and won't let me close or restart the grain.)

23:53 <abliss> (we should probably do something like what chrome does with alert(), with a tickbox to forbid all further requests)

23:54 <isd> Yeah, we probably need to implement something like browsers' "don't allow this page call alert() anymore"

23:56 <abliss> ok, now that i fixed the proxy vars, `curl --insecure` works as expected (yay!)... but regular curl complains `invalid CA certificate (24)` and drops the connection (which i guess is what's causing the "bad mac" error)