robryk @robryk@qoto.org

@TechConnectify At such temperatures (apart from places with significant ground movement), why would anyone use a heatpump with cold end in air? It seems to me that digging a well for a ground heatpump would be very quickly cost-effective.

@filippo Also, this seems to violate the implied expectation that `fetch` modifies only remotes and FETCH_HEAD :(

@filippo I didn't know that you could pull all tags at once until now.

Rereading a novel I got amused by:

> Wanaka’s rather grim smile could just be made out behind her mask. “Until we get a better idea,” she
gestured. “All hands, start thinking.”

@isomer @cks @dgl

A kind of magic you can use is:

on the shell side: give the program an stdout that's an (anonymous, from socketpair) Unix stream socket. If you receive an fd over it as the first ever thing sent over, read metadata from that fd.

on the program side: try to send a pipe fd in the blind into stdout. if it succeeds, write metadata into it (ignore EPIPE in case the other end dropped it on the floor).

This can also work for intermediate parts of a pipeline, as long as shell instantiates the pipe as a stream unix socket.

@isomer @cks @dgl

What kinds of shortcuts? I don't see any better ones than "just specify what it actually is, when you get an error telling you »you must specify what this thing (which seems to be json) is«".

@isomer @cks @dgl

So you have the option of requiring that the user tell you what it is or trying to guess. If the user tells you the wrong thing, it will simply never work so will be ~immediately noticed. I see a clear difference in safety between this and "usually works unless your csv file contains a field with long enough piece of json".

Also: terminal? Are you talking about people writing/reading that input by hand/eye, or did you also mean pipes/sockets/fifos/...?

@isomer @cks @dgl

That sounds like yet another nightmare similar to browsers' mime type sniffing, with similar consequences~~

@isomer @cks @dgl

Based on the bytes of stdin or based on some other sources?

@SomangTheTiel @hedwyg @ct_bergstrom

Do you know whether birds react differently to people wearing an eyepatch?

@isomer @dgl

You can also require a converter _always_ and use its presence as an indication that this is an object, but this is somewhat more verbose anyway if it's actually json \shruggie{}

@isomer @dgl

Are those other things representable as json, or do you want to extract e.g. metadata nonrepresentable in json and somehow make it accessible?

If former, then you don't really need anything: one could always pipe the whole thing through a converter (and then maybe something other than JSON is a better choice for the thing the shell actually understands?).

Also, you could have shell builtins that can only be used as last stages of a pipeline in $() construction and that "emit" "objects". In reality, their presence there is pure fakery and they have no byte-serialized output format: they just indicate how the thing should be parsed.

Hm~ thought experiment: how would the world look like if trademarks could only be owned by corporations[1] with a responsibility only towards upholding the trademark's reputation[2]?

[1] question of ownership unresolved (theoretically it should be immaterial)

[2] question of who has standing to argue that they're not fulfilling this duty also open

cc @TechConnectify @aredridel

@TechConnectify @aredridel

I can kinda understand them thinking something along the lines "any positive mentions of word Disney are bad, because they indirectly make the current owner of the trademark appear to be better".

When I say it that way it sounds like the notion of trademarks being property that can be traded is a nontrivial contributor to that approach~~~

@isomer @dgl

The current approach to dealing with a similar problem of splitting null-terminated lists is IIUC temporarily unsetting IFS. It would be nice if parsing json and parsing null-separated lists was done in a reasonably similar way.

@landley @freemin7

So, note that the case of _poster's_ instance being malicious is not unrealistic. I would prefer if we could deal with that by having a protocol where there isn't room for malice misbehaviour, but am sad that this ship likely has sailed (e.g. you can gaslight people by sending different contents of the "same" post to different instances, and watch as they start talking past each other).

That said, fair point: something that's fetched by the _target_ instance is strictly better by quite a bit than a screenshot.

> Activepub is eventually going to need cryptographic signatures if it doesn't already have them. Shouldn't be noticeably more heavyweight than https...

When you push a message to another instance you sign it (with a key whose public key is fetchable from your instance over https). When pulling we rely on https.