[insert xkcd comic about standards]

We already have ActivityPub, no point in trying to reinvent the wheel without a critical mass of users and services.

Mastodon + Lemmy + Pixelfed are built on ActivityPub, what does your protocol bring to the table?

Well I guess I've spent two decades in software, networks and distributed systems engineering, especially quite significantly in protocols and platforms. It's not that I want to create some new protocol, it's that there's a certain inadequacy in the existing ones for service to service communication e.g http was made for hypertext transfer, its for web pages. More modern protocols like gRPC have tried to do this thing but as rpc with a binary protocol that is largely obtuse and has not shown itself to be more widely adopted as a standard for open services.

I think ActivityPub is specifically geared around social communication whereas I'm thinking more like the services layer or what we currently do in random ad-hoc ways as HTTP APIs.

For me, the protocol is about creating something very standard for API services that are human readable and can exist alongside SMTP and HTTP. Again, didn't set out to create yet another protocol, I'm just not seeing great standards around services.

Personally, I think its great to think about protocols and the tech that goes into it... but only because its interesting to me technically.

Some of this kind of sounds like: I have a cool protocol and now Im in search of a problem that I can apply it to. What app should I duplicate first?

You need to flip this around and ask: what kind of service can I build that would deliver new or additional value to users, that is a significant enough improvement that users will switch en mass.

Then go do that, get a bunch of users, and then release your protocol and encourage others to participate.

There's nothing wrong with doing it all in parallel, but the primary problem -- getting users -- is large enough to consume all of your energy.

Well, to come up with the applications, you just have to go back to the original rationale to use computers: to automate the generation of some kind of answer to a question. The automation should be either equal to or higher quality than a manual alternative, or so much faster and cheaper that lower quality is acceptable.

When we look at that in terms of service interfaces, it's an attempt to black-box some part of answer generation, to say "this other party will do that"...which means that it's orthogonal to the answer itself. The most direct way to get good answers would be to already know them, and everything else, like the question you ask of an interface, is secondary. Interfaces tend to be a point of friction to accessing answers because they have to assume in some sense that you know what you want to ask and how you want to phrase it. If you got the right answer from asking the wrong question you'd be extremely pleased but also confused.

So it helps to establish concretely what kinds of questions are asked for each application, and turn those into interface specs. That's where a lot of the design challenge is - capturing the question/answer cycle succinctly, without overgeneralizing.