ether+nick

@evan
There's also the possibility that the server has a relay set up, which is usually recommended for small servers to do if they want content from more of the fediverse.

My initial numbers seem to show that the number of people needed to provide data to tags.pub is very low -- just a small percent of the total number of active accounts on the Fediverse. But I need to firm those up.

That assumes that everyone follows different people. That's unlikely! There's usually a lot of overlap. So, if we use an overlap factor c, the max number of remote accounts is c * N * M. I'm trying to figure out that overlap factor -- especially if it is constant or varies with N.

A cheap way to estimate is that on average everyone on your server follows M people. ('followers' scales in a power law distribution, but 'following' is bounded by human attention and seems to stay under 1000 for most people. Using the mean here is valid.) So if your server has N users, the max number of followed remote accounts is N * M.

Note that this is just for estimation. tags.pub is not in competition with Mastodon hashtag following. They're complementary; you can do both.

I want to estimate how many people we need providing data to tags.pub to have more potential content than:

- the median server size (about 50 users)
- the server size of the median user (about 100K users)
- the largest server on the network (about 3M users)

That gives me some growth goals.

My next project is about scaling .

If you follow a hashtag in Mastodon, the number of people that provide potential content to you is total number of people on your server plus the total number of unique people followed by everyone on your server.

If you follow a tags.pub account, the number if people that provide potential content to you is the total number of unique people that provide content to tags.pub -- through relays or the followback bot.

Woohoo! I'm finished. I found a bug in my code this morning that cleared up 5-6 other bad results. Submitted my assignment with hours to spare.

Now I'm going to take a nap and then move to my Airbnb in the old centre of Milan.

CBOR is a compact binary data serialization and messaging format. The @w3c "CBOR-LD 1.0" specification defines a compact binary format for , built on CBOR and compatible with -LD, designed for bandwidth-constrained environments and efficient storage
➡️ w3.org/TR/cbor-ld-10/

It helps achieve semantic compression and smaller payloads, often delivering 60% or greater savings compared to generic compression.

Feedback welcome! github.com/w3c/cbor-ld/issues/

@philip I don't think it's a good idea for me to convince you either way. Use a search engine if you're curious. If you find evidence that makes you think one way or another, use that to inform your answer. If that's more work than you think a poll is worth, feel free to skip the question.