This way of developing the #fediverse where each server only receive one kind of the objects accepted by #ActivityPub makes it more fragmented it, right? A server should send and receive all kinds of objects and should be up to the client to how to processes those objects.

If an user wants an Instagram-like app just create an account on any service and use and app with that UI, of lager they wanted to see more kinds of objects they should just use another client that supports Note, Article, etc. with the same account on the same server.

Ideally all server should have a shared API.

This fixes #fragmentation, the need to have multiple accounts if you are into multiple kinds of objects/content.

you are viewing a single comment's thread
view the rest of the comments

[–] hperrin@lemmy.world 1 points 4 days ago* (last edited 4 days ago)

I didn’t say basic. I said bad. HTTP 1 is a good protocol. ActivityPub is not. Read both the specs if you don’t believe me. I have.

There’s not a single point in HTTP 1 that I thought, “what the fuck does that mean?” There are several in ActivityPub. ActivityPub also has several areas that are ambiguous. Ambiguity is bad in a specification.

ActivityPub tries to support everything, and has no defined behavior for when a client doesn’t support whatever thing it just received.

It also uses JSON-LD, which isn’t necessarily bad, but defeats the purpose of JSON by making it too complicated to easily write by hand.

This is not easy to write, read, or parse, or build:

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/workplaceHomepage",
      "@type": "@id"
    },
    "Person": "http://xmlns.com/foaf/0.1/Person"
  },
  "@id": "https://me.example.com",
  "@type": "Person",
  "name": "John Smith",
  "homepage": "https://www.example.com/"
}