robryk @robryk@qoto.org

@kornel

Actually, a better example (granted, it's harder to find them but it feels like there's some knowledge-graph-style preprocessing happening):

> Which is larger: dog or a year?

> A year is much larger than a dog. A year is a measure of time, while a dog is a living animal. A year is typically 365 days long, while the size of a dog can vary greatly depending on the breed. Some breeds of dog can be quite small, while others can be quite large, but even the largest breeds of dog are still much smaller than a year.

@kornel

You just need to be less typical in your nonsense:

> Is there more quarks in a story than in a show?

> There is likely to be a similar number of quarks present in a story and in a show. Quarks are subatomic particles that are the building blocks of protons and neutrons, which are the components of atomic nuclei. Quarks are not directly relevant to the content or format of a story or a show, because they are too small and too far removed from everyday experience to be directly observed or experienced. A story or a show is typically a narrative or a performance that is created and presented by human beings, and it does not contain any quarks or other subatomic particles. It is therefore not meaningful to compare the number of quarks present in a story and in a show, because they are not directly related to each other.

@kornel

My impression is that all of these models are useless at generating true statements. E.g. I ask chatgpt "What is the halflife of aspirin in blood?" and it tells me it's 20minutes (actually it's between ~2h and ~10h depending on dose). There's no way to tell, based on the answer alone, that it's wrong: it's not outrageously wrong (well, given the dosing recommendations it does sound low, but not impossibly low) and the answer is grammatically correct. So, to verify the answer I actually need to go to as much effort as finding it would take.

@sqrt2 @rysiek

Usually inaccurate specifications of expected behaviour are considered "software bugs", because writing the specification is part of designing the software. In that model, these two statements are not equivalent.

@gregeganSF This situation will happen for any continuous (for L1 distance between probabilities) definition of entropy: if you bring your probability-of-being-not-in-pocket to 0, the limit will be entropy-of-a-constant, and yet on every point where that probability is nonzero the entropy-conditional-on-not-in-pocket will be unchanged.

@gregeganSF The thing that is smaller than the original entropy is the expected value of the new entropy after the "check in the pocket" experiment.

@nandalism

So the message goes to your followers, who see it in their Home feeds? I was under the impression that home feeds don't display messages that are replies (i.e. have inReplyTo set) usually.

@dunkelstern

But also you don't want to share the branch, but share the contents of the working directory. I.e. even if it worked, it wouldn't be doing the intended thing.

@dunkelstern

You can push into a local or remote-over-ssh-repo.

If you have a checked out branch and are trying to push into that branch, the push will fail: you just need to check out something else (or even the same thing, just in detached HEAD mode). See the full error message at https://paste.sr.ht/~robryk/67de3b229005455bbd0abfd11d7ac20dc2ee3805 that explains alternatives. Note that this would happen regardless of how you access the repo: it's simply that git refuses (by default) to push to a branch that's checked out.

@dunkelstern @alison

I can't see the original question, so I might be missing some piece of context.

Pushing and pulling works with ssh remotes, as well as local path remotes.

@nandalism

What do you mean by "Honk client"? Do you mean using sprayandpray?

> go to all my followers.

Am I right in assuming that you mean "the followers' instances receive it and display it in their Home feeds, even if those followers are unmentioned in to/cc otherwise"?

> I also wonder how does a server know who sandestin's /followers are? It must query a sandestin endpoint to find out. By avoiding that I avoid an extra step in the puzzle and avoid the question of sync problems.

It is expected to attempt to query it, and also the instance of that user is expected to forward it (see https://www.w3.org/TR/activitypub/#inbox-forwarding) when it receives it (there's nothing that guarantees that it would receive it, so it's a very weird hack).

@nandalism

> I thought being explicit in CC and having a low follower count would allow me to sanely troubleshoot without adding another variable to the mix.

On one hand, yes.

// Hmm... I wonder if that makes it show up in "direct messages" feed in Mastodon.

On the other hand, it's an additional difference that might or might not matter for how the message is displayed, so sadly it might be worthwhile to try both or to actually bite the bullet and read how Mastodon interprets these lists.

@nandalism

What do you mean by "followers minus originuser"? Do you expand the list of followers yourself?

I thought that ~everyone did that by literally mentioning the followers collection in the cc list. Not sure whether there's any reason (other than making messages smaller) to avoid expanding, but Chesterton's peeking over their fence.

@nandalism

> I assume your idea is to give the replying user control over visibility.

Yes.

> Again, the only reason I don't have as:Public in CC too is that it doesn't seem to help and I think it might cause reply-spamming (maybe not).

What it changes is that others can look up the post (by link) and see it. If as:Public is not in cc, then fedi instances will consider the to/cc lists as the ACL for read access to the post.

@nandalism

I would be very surprised if adding as:Public to cc would change anything in how the message is presented to users who are already in the expansion of to/cc.

> I mean the test user I have set up on the mastodon server (@andalism). I use Honk normally.

Aaaah, the user sending the command, not the bot user. Thanks.

@nandalism BTW. I just realized that in that model there's a very natural way of specifying targets of messages: use standard e-mail rules (i.e. "to" author of the command, "cc" to everyone the command had in to/cc).

The nice property of that is that it allows players to determine privacy of the game by simply setting privacy of the commands.

@nandalism @objectinspace

WDYM by the case when the sender is the Mastodon user? I don't think Mastodon ever generates such a message.

@nandalism @objectinspace

Note that sending anything "to" as:Public makes it not unlisted.