@hrefna@hachyderm.io
@hrefna@hachyderm.io avatar

hrefna

@hrefna@hachyderm.io

SRE at Google. Queer. Poly. Trans. Engineer. waterprinciple on twitter. Ace. Member of AWU-CWA. #ActuallyAutistic #UnionStrong

This profile is from a federated server and may be incomplete. Browse more on the original instance.

hrefna, to random
@hrefna@hachyderm.io avatar

This issue is a good illustration of like… 60% of my problems with SWICG https://github.com/w3c/activitypub/issues/429 #ActivityPub

hrefna, to random
@hrefna@hachyderm.io avatar

The recent incidents have hilighted to me one of my personal struggles with #ActivityPub

My first questions when developing a writeable API are 1. who can call this endpoint 2. what does the payload accepted by this endpoint look like?

AP is largely silent on (1) and is, for lack of a better term, actively hostile to (2).

Then I look at it from a database side and I try to draw a line between the use case and the schema and connect that to the payload.

Which again, AP is hostile toward

1/

hrefna, to random
@hrefna@hachyderm.io avatar

What I personally want more than a good test suite in #ActivityPub, and possibly a lower bar, is a good reference implementation.

Specifically, I'd want something that:

  1. Implements all nontrivial requirements of the spec.
  2. Implements a significant percentage of the data vocabulary
  3. Can handle a nontrivial amount of traffic. It doesn't need to be optimized for it, but it can't fall over in a stiff breeze—analysis should be comparable to analysis of a prod system, just at smaller scale
hrefna,
@hrefna@hachyderm.io avatar

I think in many ways a test suite would be more generally useful, but part of what I personally find challenging is simply determining what it even means to "handle a response."

A reference implementation would solve this.

I know of a few efforts in this regard, but most of them seem to have an iron triangle around the three criteria above:

One or two of the three only. Never all three together.

So far I have developed some heuristics when looking at implementations here.

hrefna, to random
@hrefna@hachyderm.io avatar

The thing about the 'Big fedi, small fedi' article is that it sets up a false dichotomy.

I think that the fediverse can be very big and also much safER than extant social media (or the fediverse as it sits today).

Moderation can require a human touch and moderation can also be rendered much less necessary by automated tools (note I didn't say "we can do moderation by automated tools," I'm making a very nuanced distinction between moderation and other safety tools).

etc.

1/

#fediverse

hrefna, to random
@hrefna@hachyderm.io avatar

I sort of want:

  • To/cc to control where the message gets sent.
  • Audience to control who can see the message.
  • bto, bcc to not exist or be broadly disabled in AP (edit, to clarify: I want to and cc to take the meaning of bto and bcc in general; the functionality is useful, but in a social network it should be the default behavior and we have other mechanisms to tag people in)

#ActivityPub #ActivityStreams

hrefna, to random
@hrefna@hachyderm.io avatar

I don't know who needs to hear this, but the #fediverse does not need a dating app. Please please please do not create a dating app here at least until we fix some fairly substantive issues around trust and safety.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • random
  • meta
  • Macbeth
  • All magazines
    •