Another non-binding question: would you prefer Prismo to release a GraphQL API or JSON:API API ( with syntax similar to the official client-server specs of AP) ?

@mariusor that official server-client api is not a real world solution for backend-frontend scenarios (+no one ever used it)

@prismo I don't agree with you. I use it for and it works.

@prismo what did you want to do with C2S and you couldn't? Maybe I can help with an idea or two.

@mariusor and how do you handle pagination, filtering, sorting or any other stuff not mentioned by the specs? You just made it in your own way?

@prismo pagination is already covered by the Collection objects spec. But filtering I implemented my own by adding simple property=value keys to urls.

Eg. "type=Like" (for showing just Like activities in a collection). "attributedTo={actorHash}" - for filtering activities of a specific actor, etc.

@mariusor that's exactly what bothers me - no standards for basic things like that. But i can reconsider if you're saying it's working fine for you so far

@mariusor and btw - i've spoken about that with @dansup some time ago, maybe he has some valuable input in that manner as he already decided not to use C2S

@prismo personally I haven't found yet a use case (in the context of a link aggregatir) where I couldn't work with the C2S spec for getting my information.

Maybe in @dansup it's different as he might need more details about objects than AP can offer. However I would still try to do it using AP extensions instead of having to build and maintain two API layers, one for AP and one for whatever else he's using.

@prismo do what you got to do man. I was just trying to make you not give up on C2S without really investigating it (the way other implementors seem to have done it). :D

Ping me if you get into any problems.


PS. Once I am satisfied with S2S between instances probably I'll look at prismo to be the first external project to federate against. :)

@mariusor @prismo @dansup

I'm not implementing it, but I think C2S is the most preferable. Even if it's missing stuff, it's a standard by build on and its much better than every project having a different API
@0x1C3B00DA @mariusor @dansup @prismo

pubsub and similarity to TwAPI is why Pleroma FE migrated to MastoAPI (emulated on top of C2S internally) instead of C2S. streamingInbox will eventually solve pubsub.

@bhaugen @prismo anything but graphql. It's really awkward and proprietary why reinvent the wheel with your own query language and JavaScript magic (query hashing and query functions). It might for Facebook but it's really not fun to use or hack at as a user.


I go with the opinion of the devs who are doing the work. I have looked at the code, though, which I can understand, and also used it as a tester, which was pretty easy and understandable.

I wouldn't try to sell it to you, though.



I should probably clarify. I'm working with a bunch of devs who have decided on graphql for a bunch of projects. I understand your concerns about FB. I'll ask them to take a look at JSON-API.


@bhaugen @prismo I mean graphql is not bad but its not really designed to be used by piblic. It's mostly used as internal API for front end and the problem is it's really awkward to hack against as a public user. To replicate grapqhl in a script you have to get the tokens, set headers etc. It's just not convenient.

@wraptile @bhaugen setting Keys and headers is not something graphql specific. Its a mechanism of authenticating the request, any api standard can (and actually should) utilize that

@wraptile @bhaugen and also, graphql is not really reinwenting the wheel as there is no such wheel yet :) graphql is amazing thing designed to make you Able to fetch anything you want in a single query. I think you Just did not used it enough to appreciate its pros :)

@bhaugen long story short: in GraphQL consumer has a full control over how returned data is modeled and structured. JSON:API enforces you to use it's predefined scheme. Also, it really suck to parse a JSON:API response when there are includes attached (even most of node.js clients does it asynchronically as a Promise)

@prismo @bhaugen I guess it depends on the implementation really. I don't know a single open and friendly graphql implementation. Majority don't even let you send custom queries and instead they have predetermined queries that they support and you send a hash of them. When public API requires tokens and all sorts of boilerplate that's when the API has failed.

You should be able to curl a response in your terminal or type in URL in browser and see the results without jumping through hoops.

@wraptile @bhaugen i think all the graphql apis i've been working with so far were totally friendly (say, github). Also, in terms of developer-consumer friendliness, IMO even the worst graphql implementation is nicer to work with than the Best rest api (given they both share exact the same amount of data). Especially that graphql auto-suggests fields and self-documents itself. But, if the implementation is bad, its not really graphqls fault

@wraptile @bhaugen also, you totally can use graphql endpoint with curl. Its not gonna be easy for More complex queries but you totally can do that.

Ps. Graphql is never gonna be an official go-to api of prismo. Its gonna be a secondary one at most. I decided to try the C2S route as a primary one

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!