

Me neither? That’s why I was hoping they might have added some markdown extension.
I have done it in the past with mardown-it-wikilinks npm package, for example.
Me neither? That’s why I was hoping they might have added some markdown extension.
I have done it in the past with mardown-it-wikilinks npm package, for example.
Also, I’d argue the wikilinks (internal links) using [[any term here]]
from Wikipedia, that optionally allow automatically inferring the link, is much more comfortable (and less error-prone) for the usecase of a wiki system, than the [text required](/link_here_also_required_even_when_redundant)
from markdown.
I was hoping they might have added some markdown extension to do something similar, but it seems not.
Step 1. Analize what’s the possible consequence / event that you find undesirable
Step 2. Determine whether there’s something you can do to prevent it: if there is, go to step 3, if there’s not go to step 4
Step 3. Do it, do that thing that you believe can prevent it. And after you’ve done it, go back to step 2 and reevaluate if there’s something else.
Step 4. Since there’s nothing else you can do to prevent it, accept the fact that this consequence might happen and adapt to it… you already did all you could do given the circumstances and your current state/ability, you can’t do anything about it anymore, so why worry? just accept it. Try and make it less “undesirable”.
Step 5. Wait. Entertain yourself some other way… you did your part.
Step 6. Either the event doesn’t happen, or it happens but you already prepared to accept the consequences.
Step 7. Analyze what (not) happened and how it happened (or didn’t). Try to understand it better so in the future you can better predict / adapt under similar circumstances, and go back to step 1.
I don’t think “the development” is what is claimed to be at stake here.
OP is not talking about the software, they’re talking about the content. And the content model from Mastodon is not interchangeable with the one from Lemmy, Pixelfed, etc. they serve different purposes and have different models. In fact that’s the main interoperatibility barrier between them.
It’s like saying that if most people use gmail for email you will switch from email to audio calls to avoid communicating with google’s service. As if real time audio were the same thing as sending a message (or as if google was unable to add compatibility with that call service too if they wanted).
One thing you could argue is, instead of switching services, switching to an instance that does defederate if you dont want threads content. But that same argument can be said as well towards those wanting threads federation…
But dont think the point is what does the individual want (if that were the case, just use the option to block threads content for your user, without defederating), the point is what’s best for the fediverse. I think people are afraid that something similar to what happened with “google talk” and their embrace of xmpp will repeat.
Personally, I think there’s no reason to jump the gun this early… all of this post is based on a lot of weak assumptions. I dont believe that threads content would overwhelm the feeds, and if that were to happen then the software could be tweaked so the contribution of each instance to the feeds can be weighted and made more customizable, for example.