4 ms·

JSON-LD is the reason ActivityPub hasn’t taken off even more. It’s just such a pain to deal with variables that could be URLs or entire object trees. Especially

JSON-LD is the reason ActivityPub hasn’t taken off even more. It’s just such a pain to deal with variables that could be URLs or entire object trees. Especially for strongly typed languages, it’s a nightmare.

berkes 4y ago
It isn't. It isn't hard: I've built several Serde impls for Rust that handle JSON-api and JSON-LD setups (for a.o. ActivityPub). It's just an Enum and a type with some logic to parse one or the other. An if/else isn't hard. And it certainly is not the reason AP hasn't taken off. For one, because AP has taken off, and secondly because of all the reasons it would potentially not have taken off, the underlying dialect of JSON is the least of all concerns.
- mariusor 4y ago
  You're right about serializing/de-serializing the data not being difficult, but the problem lies more in how you handle that data down the pipleine after you deserialized it. Maybe rust has a better typing system that can handle the union of MaybeSliceOfStrings|MaybeSliceOfObjects|MaybeString|MaybeObject|MaybeNull[1] types better than Go does, but I can tell you - after about 4-5 years of trying to implement a clean Go API for processing ActivityPub payloads that the complexity is quite high, at least if you want to build something that can work with more than one client/service. [1] I believe that a good implementation should handle even mixed cases, where you have a slice of both objects and strings.
  - talideon 4y ago
    That's one of my root annoyances with Go's type system: it lacks sum types. Rust has sum types in the form of enums, and thus unions. People don't appreciate how useful sum types are until they need them, and then they discover how much easier they make things.
  - berkes 4y ago
    It sounds like the issue is not Json-* formats but Go's type system. And I'm not familiar enough with large go setups, but generally -in any language- anything that must handle data "down the pipeline" should ideally not be bothered about whether this link (or meta, or paginator, or whatever) is there, is of Type-T and so on: that's for middleware/controllers etc to ensure, and to transform. In other words: your business-logic should ideally never have to bother about a link being either a string or a struct or a null etc: it should be able to assume it's a MyLink.
    - mariusor 4y ago
      I'm not sure I understand correctly what you mean by assuming everything to be a "MyLink" but that's not always possible. It depends first on how deep the rabbit hole you want to go with dereferencing URLs - what logic will you employ to decide what level of dereference to full objects you stop at, and, more importantly on being authorized to access the objects pointed at by said URL. Sometimes ActivityPub activities come with properties that are IRIs that when dereferenced are giving you 404 or 401. What does your middleware do then: Retry, Abort, Fail? Also, I'm not sure I agree with your thesis that business logic needs to worry only about a single type of object, because the ActivityPub specification recognizes all of the types I mentioned in my first reply as being "valid" and if you consider their superset as being the "canonical type" you'll be wasting quite a lot of storage (memory and disk wise) when all you have access to is the plain URL.
  - UncleEntity 4y ago
    Couldn’t you just have a RDF database do the heavy lifting and use go for the application logic? I did some deep diving into RDF stuff not too long ago and all the FLOSS databases I found didn’t do json-ld but it also didn’t look all that hard to add. Just adapt the existing xml code methinks.
    - mariusor 4y ago
      Erm, I don't want an rdf database in my application, thank you. :D The main purpose for which I chose Go for the development of this project was simplicity of the build/deploy pipelines. My targets are small communities and single enthusiasts which shouldn't need a dedicated SRE to deploy a service in the Fediverse.
lcrz 4y ago
It's only a pain if you try to look at it as a JSON tree instead of a knowledge graph.

berkes 4y ago

It isn't. It isn't hard: I've built several Serde impls for Rust that handle JSON-api and JSON-LD setups (for a.o. ActivityPub). It's just an Enum and a type with some logic to parse one or the other. An if/else isn't hard. And it certainly is not the reason AP hasn't taken off. For one, because AP has taken off, and secondly because of all the reasons it would potentially not have taken off, the underlying dialect of JSON is the least of all concerns.

mariusor 4y ago
You're right about serializing/de-serializing the data not being difficult, but the problem lies more in how you handle that data down the pipleine after you deserialized it. Maybe rust has a better typing system that can handle the union of MaybeSliceOfStrings|MaybeSliceOfObjects|MaybeString|MaybeObject|MaybeNull[1] types better than Go does, but I can tell you - after about 4-5 years of trying to implement a clean Go API for processing ActivityPub payloads that the complexity is quite high, at least if you want to build something that can work with more than one client/service. [1] I believe that a good implementation should handle even mixed cases, where you have a slice of both objects and strings.
- talideon 4y ago
  That's one of my root annoyances with Go's type system: it lacks sum types. Rust has sum types in the form of enums, and thus unions. People don't appreciate how useful sum types are until they need them, and then they discover how much easier they make things.
- berkes 4y ago
  It sounds like the issue is not Json-* formats but Go's type system. And I'm not familiar enough with large go setups, but generally -in any language- anything that must handle data "down the pipeline" should ideally not be bothered about whether this link (or meta, or paginator, or whatever) is there, is of Type-T and so on: that's for middleware/controllers etc to ensure, and to transform. In other words: your business-logic should ideally never have to bother about a link being either a string or a struct or a null etc: it should be able to assume it's a MyLink.
  - mariusor 4y ago
    I'm not sure I understand correctly what you mean by assuming everything to be a "MyLink" but that's not always possible. It depends first on how deep the rabbit hole you want to go with dereferencing URLs - what logic will you employ to decide what level of dereference to full objects you stop at, and, more importantly on being authorized to access the objects pointed at by said URL. Sometimes ActivityPub activities come with properties that are IRIs that when dereferenced are giving you 404 or 401. What does your middleware do then: Retry, Abort, Fail? Also, I'm not sure I agree with your thesis that business logic needs to worry only about a single type of object, because the ActivityPub specification recognizes all of the types I mentioned in my first reply as being "valid" and if you consider their superset as being the "canonical type" you'll be wasting quite a lot of storage (memory and disk wise) when all you have access to is the plain URL.
- UncleEntity 4y ago
  Couldn’t you just have a RDF database do the heavy lifting and use go for the application logic? I did some deep diving into RDF stuff not too long ago and all the FLOSS databases I found didn’t do json-ld but it also didn’t look all that hard to add. Just adapt the existing xml code methinks.
  - mariusor 4y ago
    Erm, I don't want an rdf database in my application, thank you. :D The main purpose for which I chose Go for the development of this project was simplicity of the build/deploy pipelines. My targets are small communities and single enthusiasts which shouldn't need a dedicated SRE to deploy a service in the Fediverse.

lcrz 4y ago

It's only a pain if you try to look at it as a JSON tree instead of a knowledge graph.