Part of the reason that people chill on ActivityPub is that the purpose of a protocol is in part to make it easier to talk to others _and be understood_.

Hrefna (DHC)

But AP _doesn't_ do that except in a very, very narrow set of contexts. Not without a lot of "whackamole driven development."

FEPs do not solve this issue and cannot solve it without a great deal of additional work (which is not a criticism of the people doing the work there already, this is a statement about what needs to exist for AP).

Hrefna (DHC)

The reason it doesn't work for this purpose is simple.

Let's say I want to build a system that requires approval before accepting replies.

There's nothing in AP that stops me from defining an accept/reject semantic and mapping all replies into the replies field (more on this in a second), then simply declaring anything else as "not a reply" and discarding it outright if it populates inReplyTo.

Now. Which services will work with my variation here?

None. Mutual incompatibility.

Hrefna (DHC)

Oh, so that's not a fair example because it involves a change of behavior. I'm introducing side effects.

k.

So let's introduce no side effects.

Now there are no replies anywhere and the only way to find replies is to do a laborious search of the inReplyTo field. This means we cannot ever have reply controls.

Oh, and flag doesn't work at all. You can't flag anything because you don't know who the flag needs to go to. You can tell people that their own posts are in violation, that's it.

Hrefna (DHC)

Okay okay, we'll all collectively agree that accepted replies just go into the replies field. That's it.

Wait how many ways are there to structure the replies field again? I stopped counting at around 30 last time I looked into it. Ugh. Okay, I've mapped all of these out and I have it working with all of them now.

But we've gotten that sorted and we use the context field and…

…wait _how_ is the context field structured again?

https://www.w3.org/TR/activitystreams-vocabulary/#dfn-context

I'm in hell.

https://media.hachyderm.io/media_attachments/files/113/363/313/066/518/991/original/f7182dd93aa312b1.jpeg

Hrefna (DHC)

Now let's say you are a security-minded individual or a distributed systems professional looking at all of this.

You come at this and you look up the OWASP API Top 10 to figure out how to secure your API surface and…

…how much work do you need to do before you can even _start_ writing your application in order to do even _basic_ input validation and feel confident in your implementation?

Hrefna (DHC)

The three top things we need IMO:

1. An extension registry. Not a way to get into the AS @'context, an honest to goodness handshake system so that two systems can know if they are compatible.

2. A conformance test suite.

3. An object validation mapping that lets me know if an object is acceptable before I start serializing it into the database and that provides meaningful checking.

Without that, I'm not even sure what AP is bringing to the table.

alphakomet

@hrefna suggestion for 3: make json-schemas normative that just _happen_ to be json-ld. Freeze the @context object, remove all prefix definitions from the AS context file. That should give you a somewhat type-safe API. I think?

Hrefna (DHC)

@alphakomet I highly recommend taking a stab at doing that. I've done it several times now and the challenges you encounter are extremely instructive.

I've also been informed that this is the wrong approach by Evan, so ‍️

Jenniferplusplus

@hrefna the amount of effort that's gone into producing a test suite, and so little to show for it. I strongly suspect it's not even possible to define conformance, much less prove it

Hrefna (DHC)

@jenniferplusplus Agreed. It's essentially an intractable problem.

Laxystem (Masto/Glitch)

@hrefna hey how does that sound exactly like my opinion.

/etc/init.d/witch.navi

@hrefna isn't 3 the job of a library? that is what my library (libactivity) will do mostly, parsing json-ld into higher level structs. if it fails to parse, it is not an acceptable object

for 1, i want to look at what wayland does for it's extensions. FEPs as is are... useless to say the least. wayland-protocols have current implementations as members, and to get a protocol extension in, you need to implement it and have it be ack'd by existing members (the number of acks changes depending on the namespaces, wp-, xdg-, ext-)

Hrefna (DHC)

@navi A library would help here, but given that absolutely no one fully parses it today or implements it today, and simply parsing it is insufficient in itself, it is inadequate.

There are virtually no required fields, so what does it even mean that it parses as valid JSON-LD?

There are over 30 different ways that a collection can manifest and a parsing library is not what will make that a navigable set.