Notices by Hrefna (DHC) (hrefna@hachyderm.io)

You are saying that our basic humanity is contingent on whether _you_ _like_ _us_.

Which is absolute BS.

I despise Caitlyn Jenner and Blair White. I don't deliberately misgender either of them or treat misgendering of them as a "well I hate them so it is okay." Doing so would be _transphobia_.

So if you see this in your orbit you need to be calling this out, or calling the person who is doing it in, or you are complicit.

Period. Full stop.

If you deliberately misgender someone and think it is okay because you don't like them, or because they hurt you, or any other reason:

That. Is. Transphobia.

I don't know why this is hard for people.

That. Is. Transphobia.

If you see this and you are in the person's trusted orbit and you _don't_ call it out or call them in (even privately) that is also transphobia.

Having trans friends or trans people who agree with you does not obviate this in any way, shape, or form.

It is dehumanizing.

Draft of my (to-be) FEP for audience targeting and filtering is up at https://github.com/larpconnect/featherpub/blob/main/feps/8f9c/index.md for those that are interested.

I haven't submitted as a FEP yet (and won't for a while), but that's the ultimate goal for it.

#FeatherPub #ActivityPub

"Aren't you opposed to blocklists?"

Not at all, I'm opposed to badly run blocklists

I'm opposed to lack of accountability in blocklists

I'm opposed to portrayals that blocklists = T&S

I'm opposed to blocklists that refuse to learn from history

I'm opposed to blocklists that do not consider concepts such as attrition, turnover, and change

Blocklists have a place, but there are strong limits to what works there and what you can do, and a lot of harm that can happen when you get it wrong.

@helge The problem is that is the only widespread use for it and there are almost no times where #'main-key or whatever is a better choice than /mainKey.

For example using <uri>#'amy is fine for selecting "amy" out of a list of users, but there's almost no situation I can think of where you would want to do that: I shouldn't be returning lists of actors of which "amy" is one of them, as a general rule, and relying on people implementing it when it isn't a documented requirement is perilous.

Spent some time on my #ActivityPub project today getting #PSQL set up. There's a lot of random setup that goes into PSQL and it isn't especially well documented (or rather, it is so well documented there is simply too much of it).

Whether I stick with it is a separate question. Comparing it to the other options and including the learning curve it is head and shoulders the best pick for me for right now, however, at least for a production-level database.

Still looking at #sqlite3 for testing

There are some other good options I may investigate later, but PSQL:

1. Is Fast.
2. Is Free.
3. Is well supported.
4. I am _intimately_ familiar with the ins and outs and how to optimize it.

I already have a lot of things on this project I am learning fresh, so it makes sense to limit the scope to be a bit more manageable for now and I can revisit it later.

Others in the space:

* MariaDB — I am familiar with the basics but only at a high level. Reasonable driver support. Some very nice features for the use case, however, something to look into later.

* Firebase and other hosted solutions — would work well enough, but would be expensive to run at scale and most options here tie you to a specific cloud provider.

* CockroachDB — Mostly seems like overkill and adds complexity.

* Mongo — I've been around too long, the name is still a curse.

Speaking of #PSQL, #mastodon, and #ActivityPub, however… 

It seems like doing table partitioning would be an obvious choice for mastodon, but I don't see it anywhere in their setup. Does anyone know if someone has done the legwork to make this work and what their results were?

@ttiurani

I've run plenty of JVM systems with nice memory footprints per user, especially on modern JVMs. Sure, it isn't the most memory efficient compared to C++, but that is also the least of my concerns when you compare it against:

1. A queue with rails worker processes.
2. A database.
3. An _ephemeral_ database (Redis)
3a. Times 2.
4. A rails API.

etc.

A JVM worker "not being memory efficient" is like Z on the cost list and trivial to lower costs on at small scale.

@maegul @aral

@ttiurani

Like we could sit here and break down the exact memory requirements you think would be "reasonable" but the truth is I don't care what you think is reasonable because it is going to be purely theoretical and your entire approach goes against how the cost of these systems scale anyways, as well as the major cost sinks in this space.

Instead put the focus where it should be: The cost of the systems today is too high for small groups to run. It needs to be improved.

@maegul @aral

@maegul

I'd also like to underscore the point there about the _cost_.

Right now mastodon is prohibitively expensive to run in terms of both time and resources. I'd see efforts to reduce this to be a net positive to the fediverse in most situations?

The lessons at large scale don't always apply at small scale and vice versa, but the point remains that right now mastodon is a bit of a trash fire in that regard and it doesn't have to be.

@aral

@ttiurani

1. There's a huge gap between "big tech" and "100 users." Fosstodon—the server you are on right now—claims 16k users.

2. That is often true, but it _often_ also has to do more with the _rest of the system_ and not just the worker process. For example: caching and dbs.

3. Using the GC is, again, like Z on the list of problems (maybe S) for the scale we're talking about and has been in Java basically since before the G1 became the default five years ago.

@maegul @aral

@ttiurani

I have run JVM based applications for nearly 20 years in production with sizes ranging between "less than a dozen users," millions of QPS, and "we're rewriting it in C++, ouch" I have run applications in Java, Kotlin, scala, and helped maintain systems in clojure.

I am intimately familiar with the overhead required.

I also can pretty much solve a problem of a few hundred users on a social media app with a rolodeck.

You are optimizing the wrong point of the problem.

@maegul @aral

@ttiurani

Is a clojure based system going to be better? Maybe, maybe not, depends on a wide variety of factors, but I'd be very curious what their _actual numbers_ are like and what the scaling breakpoints are for them and, at a minimum, their work in this field contributes to a sense of what is possible and what is easy or hard in this space.

That's the important question. Not how much memory java takes up, which is only relevant as a choice after you've added constraints

@maegul @aral

@ShadSterling

I've spoken before about how #ActivityPub is particularly weak to this problem because it's not really a protocol in and of itself but more of pattern for building a family of protocols.

It's trivial to add extensions that others may not be able to parse, and there's not even a registry or a good way of saying "I am using these extensions," so you get instead this situation where "are these compatible? glhf!"

@smallcircles @Blort

Actually effective strategies against #Meta to prevent an #EmbraceExtendExtinguish are difficult, but they start from asking "what will actually help here."

I maintain that preemptive #DefederateMeta is ineffective for this and that defederating from those who won't defederate from meta does more harm than good.

But what will help is thinking about the roadmap and getting there first. What will help is building a robust and thriving community around #ActivityPub and other fediverse protocols.

Meta is looking to implement post importing. That's been a feature request since forever (see https://github.com/mastodon/mastodon/issues/177 and https://github.com/mastodon/mastodon/issues/12423 ).

Secure messaging is another example.

These are things that if meta implements them and does even a halfway decent job then #meta controls the standard.

Want to prevent that?

Get there first or at least have a strong offering on how to do these things out of the gate. Let _us_ as a community control the standards that we use.

@ShadSterling

Really I suspect the reverse: it will make it easier for Facebook to do the "extend" portion of "embrace extend extinguish."

The "extinguish" phase only comes after people have started swapping to their custom extensions and even their own custom protocols. It creates a situation where "meta is the center" and that is not healthy for the rest of the fediverse.

@smallcircles @Blort

IMO you should never recommend:

1. "A VPN"
2. Tor
3. Blanket absolutist statements about protecting data privacy

Unless you are _very willing_ to explain the threat model you are working under and how you think what you are telling people will connect with that threat model.

If you aren't doing that or willing to do that you are doing people a disservice.