This is an interesting (pronounced like "frustrating") thread.
-
Noah Kennedyreplied to Hrefna (DHC) on last edited by
@hrefna @jenniferplusplus that is an incredibly good way of putting it
-
Michael T. Bacon, Ph.D.replied to Jenniferplusplus on last edited by
Ooft, yeah. I've been doing a bunch with RDF and JSON-LD recently in non-AP contexts, and there's a huge amount of power there but HOLY PEAS it is NOT an interoperability standard, nor could it ever be one, I think. They are ontological data format and linking standards that REQUIRE a strong defining model for interop.
I'm a fossil from the old days of the IMAP and friends IETF standards. AP is so freakin' wobbly compared to those.
-
Hrefna (DHC)replied to Hrefna (DHC) on last edited by
Sometimes they hit on a core concern or problem, but then they keep asking "but what if" until people ignore 90% of the spec (XML I'm looking at you) and/or it gets applied to other specs that then get ignored (how many XML specs are there?). Many times the spec seems so abstract as to be unimplementable in a useful form (DIDs! you're up!)
But there's now a spec!
β¦that no one uses or can use. But it exists!
Specs for the sake of having specs.
-
@jenniferplusplus @julian discovered firsthand when working on my toy AP poster that Mastodon won't even do the "right" thing with an "image" object - instead of converting this to an embedded image in a post, it just shows it as a plain link! have to use their Attachments thing to a note activity to get that to work
-
Hrefna (DHC)replied to Noah Kennedy on last edited by
Heh, that's basically the thing I've been working on that I keep getting discouraged/overly frustrated by.
-
Hrefna (DHC)replied to Michael T. Bacon on last edited by
Yeah, that is one of the core points that BlueSky discussed in "why not AP":
Because if you want interoperability the RDF-isms just. don't. work. To the degree they do work, it is extremely expensive to validate and work with.
It's a model for describing things, not a model to be _understood_ about the things you are describing. That requires separate, out-of-band communication.
-
silverpillreplied to Jenniferplusplus on last edited by [email protected]
@jenniferplusplus I think when it comes to objects, duck typing is a good solution. Look at properties instead of types
-
Jenniferplusplusreplied to silverpill on last edited by
@silverpill @julian it's not a strong argument for activitypub if it can't be effectively implemented in languages with compile time type checking
-
silverpillreplied to Jenniferplusplus on last edited by
@jenniferplusplus @julian My project is written in Rust and for me duck typing AP objects is not a problem. I don't have experience with other languages, but there shouldn't be any problems with them either
-
Sir Alecks Gatesreplied to silverpill on last edited by@silverpill @julian @jenniferplusplus
Yes, it's quite easy to parse JSON in rust at compile time. There's even a package to generate a struct from a JSON schema. -
Jenniferplusplusreplied to Sir Alecks Gates on last edited by
@agates @julian @silverpill there's no schema to any of this
-
Sir Alecks Gatesreplied to Jenniferplusplus on last edited by
-
smallcircles (Humanity Now π)replied to Hrefna (DHC) on last edited by
@hrefna @noah @jenniferplusplus
Think in a way this corresponds to trends we see everywhere.
I was pretty deep in XML working in print industry at the time, and most these standards made good sense. I got empowered with each new spec. But elsewhere vendors hyped SOA, came with super expensive "enterprise service buses" and XML a universal hammer. Until people said "Let's ditch it all".
Now we have this with cloud complexity, and e.g. people's personal websites having FAANG-like techstacks.
-
@jenniferplusplus I also think #ActivityPub spec seems to be designed in early 2000s where users were supposed to just trust the servers. The only way I can truly own my identity is by running my own AP server on my own domain. Content is also referred to by its URLs, not by its content-hash which makes sure that I remain dependent on other servers/intermediaries.
#Bluesky at least recognizes some of these issues.
-
Nik | Klampfradler πΈπ²replied to nilesh on last edited by
Content being identified by IRIs (not URLs) is the backbone of the web. It could probably be other kinds of IRIs, yes, but don't drop the IRIs. And make sure they always stay dereferencable through HTTPS.
-
nileshreplied to Nik | Klampfradler πΈπ² on last edited by
@nik @jenniferplusplus What's this IRI you speak of?
-
Nik | Klampfradler πΈπ²replied to nilesh on last edited by
Basically, what you refer to as a URL (which, for the current state of the Fediverse, mostly is the same because virtually all IRIs of ActivityPub contents are URLs today).
But actually, ActivityPub content has an IRI, which does not have to be a URL, not even today: https://en.wikipedia.org/wiki/Internationalized_Resource_Identifier
-
nileshreplied to Nik | Klampfradler πΈπ² on last edited by
@nik @jenniferplusplus IRI seems to be about just allowing extra characters, not content-addressing.
It would be easy enough to build content-addressability within existing URLs. For example:
`https://myblog.com/my-article-<multihash>.html`
Web browsers could have built this universally for all resources when defining the SubResource Integrity spec which is ensures that JS scripts a page downloads has not been tampered with. They chose `<script integrity="<hashalgorith>-<hashvalue>">` instead.
-
Nik | Klampfradler πΈπ²replied to nilesh on last edited by [email protected]
The difference is the third letter β I vs. L.
An IRI (or URI), in contrast to a UR**L**, does **not** need to be a concrete HTTP address on the public web that can directly be loaded from a web server.