From my own experience querying public mastodon timelines via API (edit: removed incorrect /api/v1s in the AP_IDs):

• Mastodon user accounts have an ActivityPub URI of https://<instance.domain.tld>/users/<username>
• Mastodon posts have an ActivityPub URI of https://<instance.domain.tld>/users/<post_author_username>/statuses/<post_id> (they also have a url property of https://<instance.domain.tld>/@<post_author_username>/<post_id> but that tends to serve the html view of the post)

To see for yourself, pick an instance that allows viewing their public timeline without logging in (mastodon.social is perfect for this) and follow the “Playing with public data” section of the docs. That page ellides most of the info you’re looking for in the example payloads they give (as the JSON payloads themself are quite large and nested), but I can assure you that AP_IDs for user accounts and posts can be found pretty quickly from a single timeline query.

I don’t think Mastodon has any notion of community, nor does it distinguish between posts and comments (when following a lemmy community, both posts and comments show up in my masto feed as “top-level” statuses (ie posts)).

Oh nice, I always thought that was for disabling multiple rules with a single line. Cheers!

Oh nice, I always thought that was for disabling multiple rules with a single line. Cheers!

I guess that’s a tad better, though if the rule is named react-hooks/exhaustive-deps then we’re still not explaining why we’re disabling it.

What I’m really looking for is something that explicitly tells the programmer/code reader “this blows up into an infinite loop if we respect exhaustive deps, but here we don’t need exhaustive deps for the code to be sound”.

My own, hair-baked proposal: have the linter recognize [foo, baz /*, @causes-infinite-loop bar */] (or something along those lines) as an explicit, programmer-validated escape hatch for not respecting the exhaustive-deps rule.

As someone who started using react about 6 months before they introduced hooks, I remember there was a period where people were really complaining about having to manually reason about what went into every single hook dependency list. Eventually the linting rule was published. I distinctly remember appreciating the rule in situations where a variable that used to be a “plain” variable became a useState hook - it caught some existing uses of the variable in hooks that otherwise were unrelated to the code being changed.

I also distinctly remember being disappointed that there was no specific way to annotate code that needed to disable that rule to prevent infinite loops, just a generic // @eslint-ignore… I guess they still haven’t shipped a better way?

If we want to keep it silly, then "pie-munchers’ gets my nomination.

Op, I appreciate that you seem to be genuinely interested in these topics, and are not just farming engagement (which is kinda meaningless here on the Fedi, anyways…). If I may offer a suggestion, try to find a tone that doesn’t sound like a roadmap for some corporate brand strategy. Most of us that are here and would be interested in a “fediverse permaculture” are severely put off by the structure of your post, not to mention it lacks in depth for most suggestions to be directly actionable (for example, the merch you would sell to support the insurance still needs to be made somewhere, by someone, who either needs to be paid for their time or are already independently wealthy).

Have you taken a look around !permacomputing@slrpnk.net ? Permaculture is not just about principles of mutual support but also a long process of experimentation to see which combinations of which plants and practices works out “for the best”. You might foster more of the conversation you’re looking for if you can bring some more concrete examples or proposals to serve as topics instead of an all-encompassing manifesto post.

The next time I’m about to moan and complain about how nobody directly implements activitypub apis “the standard way”, I’ll remember this article and be mollified.

As @abeorch@friendica.ginestes.es states, diversity is a strength when it comes to resisting capture.

Not who you’re asking, but I assume you find either an instance that is slow to federate, or one that doesn’t honor deletion requests.

Same, it’s impressive how much it irks people.

My own hasty judgement is that [those upset] only speak English, have a prescriptivist take on language (albeit unconsciously), and have no idea how damaging hegemony and uniformity for their own sake can be.

Also they’re lazy and would rather shame someone than take on a little bit of discomfort to adapt to them.

I guess that makes it “judgements”, plural.

(youtube) explainer link for the unfamiliar : https://youtube.com/watch?v=ABpT6e-KlOo

For instances that already have a user base, admins should not make any significant decisions without the consent of their users. This goes against our values, and we will not permit an instance to use Bridgy Fed in this manner. We’ve had conversations on how to handle a situation like this, and we would block instances [3] from doing so. We strongly expect admins to be loud about bridging, especially during signup. 3/10

This is very encouraging to read from a project that initially did not understand why many would be opposed to an opt-out bridge to ATProto.

Eleventh is a static site generator. You run it once, then straight up serve the files it output.

Server-side rendering is like running eleventy for each incoming webrequest (albeit only for the requested page(s) instead of the whole site).

Phind has been decent for me when I’m looking for prior art and/or research papers on something I’m trying to develop/implement. It’s nice to be able to pose a question as I would to a colleague and get references back that I can read for myself.

Sadly, it still hallucinates some stuff, and when it doesn’t it tends to give me references that are tangentially related to my query but don’t actually cover it.

Very intriguing! Unfortunately none of my personal projects have yet to hit a scale where this sort of cache is needed, so I won’t be trying it out myself anytime soon.

It gives me no pleasure to learn that the business imitating japanese idol agencies was abusing their position and financials in relation to their “talent”.

Wanted to try it, signed up for the beta, still waiting on my invite code.

On the surface, bluesky integration makes sense if they’re trying to onboard people onto “the social web”. Still, I’m disappointed they seem to want to be a curated view on what they determine is a feed, and not some kind of plug’n’play feed viewer beyond RSS.

Ok but if it allows anubis to judge the soul of my bytes as being worthy of reaching a certain site I’m trying to access, then the program is not making any calculations that I don’t want it to.

Would the FSF prefer the challenge page wait for user interaction before starting that proof of work? Along with giving them user a “don’t ask again” checkbox for future challenges?

To my knowledge, there is 1 feature that forgejo has that gitea doesn’t: it can generate a new ssh key for you at the click of a button that can be used to push repo changes to another git forge.

I have several personal repos on my forgejo instance that are each setup so that they mirror themselves onto my Codeberg account at noon every day.

I also have a gitea instance on a raspi on my local network that itself will push out changes on certain repos to the (public-facing) forgejo instance.

I can push and/or pull to any of the three origins as needed, but usually I just push to the gitea when I’m at home and the forgejo when I’m not, and let the mirroring take care of propagating changes to Codeberg.

Part of the problem is also that, while an acre of land can feed a family of 4, there’s no way to generate enough surplus from that single acre to be able to afford a tractor in the first place. So the tractor creates the need for much larger farm plots being owned by a single person, which way up all the supposed extra free time the automation/mechanized tool was supposed to bring.

In the end, less people can work the land to sustain themselves and the only people better off are those who already had more than enough to go buy.