glyn @underlap@qoto.org

This is brilliant and much-needed. I particularly like "Explanation" with its context, alternatives, and discussion. I have tried to include that sort of thing in my projects, e.g. https://github.com/pivotal/image-relocation

@Logical_Error ha! I worked for a startup which VMware acquired. Then we were spun out and re-acquired, so I was acquired by VMware twice and never had to interview, which is probably just as well.

@Logical_Error Here's some general info from the UK: https://www.gov.uk/government/publications/the-essential-trustee-what-you-need-to-know-cc3, but YMMV depending on where you live!

@Logical_Error I used to work for VMware. They had a number of charitable schemes as benefits such as gift-matching and "service learning" where they would give you up to 5 days paid time off per year to volunteer with a charity etc. I used that to go to Uganda with a charity I support and help to run a children's camp. Amazing!

@Logical_Error You might consider becoming a trustee of a charity (I'm a trustee of https://www.kariskids.org/, so I speak from first-hand experience).

Or you could pick a cause and then promote it - write to your government representative etc.

Or you could pick a cause or project and learn as much as you can about it, which will inevitably turn up ways in which you can help.

Good luck! Getting involved is far more rewarding than simply wielding your credit card....

@NicolasConstant @cwebber

Thanks, that's very helpful. I appreciate you taking the time to clarify things.

Just to finish off, please could you clarify how many shared inboxes there typically are in a given instance? I'm presuming one, which will be created automatically by the instance implementation and which will be added to (the endpoints mapping in) every Actor object transmitted from the instance.

@NicolasConstant @cwebber

Thanks Nicolas, but I'm still not understanding something about the lifecycle of a shared inbox. I've probably got a bad assumption, so please help me.

Let's try an example. Suppose three users, A, B, and C on the same instance follow users D and E (on other instances like this:

* A follows D
* B follows E
* C follows D and E

Then A and C can use a shared inbox (for posts from D) and B and C can use another shared inbox (for posts from E), but it wouldn't be valid for A, B, and C to use a single shared inbox since A would then receive E's posts and B would then receive D's posts. Right?

At some point, someone or something has to decide when to create a shared inbox and it presumably has to satisfy the kind of constraints in the example above. Who or what creates a shared inbox and at what point?

> If you use GitHub, consider SourceHut3 or Codeberg. If you use Twitter, consider Mastodon instead. If you use YouTube, try PeerTube. If you use Facebook… don’t.

(via @NicolasConstant)

@NicolasConstant @cwebber Sure, but in what circumstances would a shared inbox be created?

@odesa Ok. So presumably any actors are predefined or similar?

@ilyess Yeah, a friend of mine, Florent Biville wrote it. He has a great sense of humour.

@freemo I can't find a definition of an ActivityPub relay - just various lists of them and nothing in the spec. Do you have a good reference, please?
@zpartacoos

#activitypub #relay #mastodon

@cwebber Fair enough. For newcomers like me, do you have some references to good framings?

@cwebber By local contexts do you mean the use of petnames or something else?

I got around to reading the ActivityPub spec. and it's pretty nice! I'm wondering how implementations decide when to create a shared inbox. Seems like a potentially interesting algorithm.

#activitypub #sharedinbox

@cwebber

@ilyess The reason I was aware of this was maintaining open source software with copyright headers in source files. There are even utilities to help automate this particular task, e.g. https://github.com/fbiville/headache.

@ilyess Why? Copyright dates only need updating when text is (substantially) modified.

@freemo @zpartacoos Very interesting. So the graph of nodes is "induced" by the graph of user follows.

So a node with a larger number of users would probably need to connect to correspondingly more other nodes because of the disparate social networks of its users. On the other hand, small nodes with, say, a hundred users who each follow less than a hundred others would only need to connect to at most 10k other nodes, and probably a lot less. (If there were billions of users, I think discovery would become a problem unless there are some nodes with very many users.)

@zpartacoos @freemo I haven't got a specific limit in mind, except perhaps for the number of users to be in the billions (for mass migration from Facebook, Twitter, etc.), but my thinking so far is as follows.

Suppose the graph of nodes needs to be fully connected (note: this is still an open question for me). Let's also suppose each node has one IP address (it may be possible to use a cluster of IP addresses to represent a single node, but let's keep things simple for now).

Then a given node can have at most 64k (probably less in practice) TCP/IP connections open at any one time (because each requires a 32 bit ephemeral port number). So if there are, say, 100k nodes or more (e.g. to host 1-2 billion users), then connections will need to be re-established periodically in order to keep "subscribers" up to date with "publishers" (pardon my terminology - I must read the ActivityPub spec!).

This will result in a trade-off between CPU consumption and the timeliness of delivery of messages. E.g. if we want to display any new post within one minute of it being published, we'd potentially need to cycle round all possible connections once per minute.

(If, on the other hand, the graph of nodes isn't fully connected, then some intermediate nodes would need to do more work to forward messages.)