🫧 socialcoding..
For #ActivityPub the question of "Why use #LinkedData?" has never been answered. There should be clear merits to wade through all the complexity that this choice brings, right?
Yes, its ultra flexible, and you can define your own semantic #ontologies, and theoretically it could provide a robust extension mechanism to AP protocol. Except that right now it doesn't.
What's the vision of a Linked Data #Fediverse? What great innovative #SocialNetworking #UX would it bring, that makes it worthwhile?
Evan Prodromou
Using JSON-LD lets us mix in existing vocabularies like vcard, schema.org, and foaf.
It also lets us build and add extensions without name conflicts.
Evan Prodromou
@smallcircles there are other ways to do this. But the conjunction of JSON, namespaces, and W3C made JSON-LD the obvious choice.
Evan Prodromou
@smallcircles standardizing extension vocabulary definitions is a good idea, yes. Either as SocialCG reports, or with ad hoc standards on other sites.
🫧 socialcoding..
@evan yes, that much is clear. It is the level where things make sense: reuse well-understood vocabularies.
Except my mix'n match of common JSON-LD props doesn't match yours, and we can only understand each other going the full monty on linked data support.
Or avoid the convergence in how we defined the same semantics differently by having a specs site somewhere and agree to do things the same way to a certain extend, and get reliable expectations when interfacing/integrating our apps.
Evan Prodromou
@smallcircles JSON-only implementations usually work fine. I think having a context doc that incorporates extensions and external vocabularies and untangles naming conflicts will help out a lot.
🫧 socialcoding..
@evan if we can define some intuitive best-of-both-worlds good-practices for JSON-only and LinkedData folks, then it is a problem solved. Except that JSON-only impls probably can't deal with the more flexible output coming from a more advanced Linked Data based endpoint, but that is the tradeoff to choose as a dev, I guess.
Evan Prodromou
@smallcircles I don't think SocialHub has that privileged place in the community. In general I think that developing and implementing extensions and then bringing them into the main context through the new extension policy is the right series of steps.
🫧 socialcoding..
@evan indeed. As you know I advocate for the bottom-up 3-stage Standards Process of Ecosystem --> FEP/SocialHub --> W3C SocialCG/WG
Where we should avoid that what is first emerging in the ecosystem is so non-standard that it'll never rise from 3rd-stage into more formal specs.
That means a set of best-practice guidance that is best provided from the SocialCG/WG for the entire fedi to use.
Evan Prodromou
@smallcircles There's a lot to like about FEPs. I agree, having disparate groups working on focused areas is very useful. I don't think that an extension needs to pass through SocialHub to get included in the AS2 context.
🫧 socialcoding..
Key to the proposal is that the ecosystem itself is decentralized while it works in many independent hubs and communities to evolve the decentralized technology.
There are already a bunch of hubs that recognize neither the FEP/SocialHub nor the W3C, like the Podcasting Index.
Their work is just as valid as what other people do. The grassroots ecosystem driven by the Commons determining the general direction of the Fediverse.
🫧 socialcoding..
@evan that's fine. #SocialHub is currently the default place where #ActivityPub #FEP's are discussed.
For each FEP the editor team ensures that a discussion thread on the forum is present. Other than that there is a tracking issue in the FEP repo on #Codeberg that can track other places where discussions take place and feedback can be collected from.
SocialHub isn't important, but the FEP Process is, as 2nd-stage in the Standards Process. The place that sits between no formality and formality.
Evan Prodromou
@steve @smallcircles also, ActivityPub uses URLs to identify important entities -- people, content, reactions, collections, relationships. This maps really closely with the JSON-LD use of URLs for identities.
Steve Bate
@smallcircles The data is literally "linked data". Although there are other options for working with distributed linked data than using Linked Data tech, I'm wondering what alternative you have in mind. Many developers use ad hoc implementation-specific techniques to manage it, but it's not clear to me that this is an improvement over LD.
Evan Prodromou
@smallcircles @steve Could you explain a problem for JSON-only folks? I think the main problem I'd see is if publishers use namespaced terms when they're not necessary -- like `https://www.w3.org/ns/activitystreams#Like` or `as:Like` instead of plain old `Like`. And the Postel principle (sorry Steve!) would say, don't do that, publishers. (And, also, be better prepared for that, consumers!)
🫧 socialcoding..
@steve I merely observe the huge struggle with LD. Where experts "get it" and non-experts hate it. Where there's a ton of discussion on how it should be used correctly. How its so very easy to use some LD flexibility that makes things hard for JSON-only folks.
AP on protocol level is about msg exchange, mostly Activity{Object}. Yes, technically all linked data, but it may also be usable semantic graphs once it enters your own data store, and be closed-world concrete msg definitions until then.
Evan Prodromou
> Actual practice is that there's not yet a robust extension mechanism
This is untrue.
https://www.w3.org/TR/activitystreams-core/#extensibility
Here is the extension mechanism:
- You define terms in a namespace and a context document.
- You document those terms.
- You use those terms in your published Activity Streams 2.0 documents.
JSON-only developers can just watch for terms that they are interested in; if there are naming conflicts, they can check the `@context`.
🫧 socialcoding..
For JSON-only folks it is not so much a problem as a question about merit. "Why would I use it?". In practice they don't, just throw in some @context for good measure.
This context, while minimally helpful, does not say which props are required/optional in msg exchanges to a particular endpoint and what exchanges to expect.
Actual practice is that there's not yet a robust extension mechanism, and people study codebase + issue trackers to see figure out integration with some app.
Evan Prodromou
@smallcircles @steve so, in this FEP, I defined two new properties, `pendingFollowers` and `pendingFollowing`:
https://codeberg.org/fediverse/fep/src/branch/main/fep/4ccd/fep-4ccd.md
There's a namespace, a JSON-LD context document, and documentation for how to use the terms.
If you see an actor on the fediverse with the `pendingFollowers` property, you know it's probably following these guidelines. If you want, you can check that the `@context` of the actor document includes "https://purl.archive.org/socialweb/pending" to make sure.
Evan Prodromou
@smallcircles @steve as more implementers include these properties, it can become part of the standard context for Activity Streams 2.0.
https://w3c.github.io/activitystreams/draft-extensions-policy.html
phiofx
@smallcircles @evan @steve the lack of #linkeddata killer app in the #activitypub / #fediverse context derives from not having a gee-wow usecase in any context. Bioinformatics is most avant-garde here (https://www.nature.com/articles/s41746-019-0162-5) and whenever there is a delightful surprise in tooling it is motivated by this niche (e.g #owlready https://owlready2.readthedocs.io/en/latest/).
If its good enough for physical health it should be good enough for social health but may take a long while to get there.
🫧 socialcoding..
What I mean with "robust extension mechanism" is more than a #JsonLD context. It comprises the entire set of tools and practices for writing quality #ActivityPub extensions defining data formats, msg exchange patterns, business logic, etc. so that I have biggest chances to write extensions that can interoperate well. All this may include a way to discover which extensions an endpoint supports, and able to find their docs/specs.
Evan Prodromou
We have robust ways of providing everything you're asking for.
- data formats = extension types and properties
- exchange patterns = documentation
- business logic = documentation
- interoperation = namespacing
Distribution is built into the protocol; you just have to make sure the addressing properties are set.
Evan Prodromou
@smallcircles @steve I think the one thing that's interesting in what you've said is determining if a server will manage the side-effects expected when you send an activity to an `inbox` or `outbox`. For example, if an actor posts an `Arrive` activity to their `outbox`, will the server automatically update the actor's `location`? I'd answer, design extension vocabularies such that there is a reasonable fall-back if the server doesn't implement side effects.
Evan Prodromou
@smallcircles @steve I also think that providing some more feedback in the response to a post to `inbox` or `outbox`. When a server gets an `Accept` for an `Invite` to an `Event`, for example, it might be able to give a response that says, "I understand this and will implement its side-effects", or "I'm going to distribute this, but I don't know what it means, so don't expect any side-effects", or "I'm not going to even distribute it."
Evan Prodromou
@smallcircles @steve I think having machine-readable specs is possible, but it's a lot of work. I think human-readable documentation is a better starting point.
I've got a goal to add FEPs for Event management, geo-social, and relationships. All covered by the Activity Vocabulary but not ActivityPub. I'd be happy to extend the FEP template with specifics for activity types, expected responses, and object types and try these application areas out.
🫧 socialcoding..
These are examples of business logic that a particular app or service may have in a particular domain / use case.
In a heterogenous Fediverse someone might build msg exchange for water starting to boil in their teapot. It will likely not be a #FEP anytime soon, and most probably never enter into W3C artifacts.
Still, ideally, one should be able to discover from the endpoint how this Teapot service works. Simplest is discovery where docs/specs live. E.g. via "Compliance Profiles".
Daniël Klabbers
@smallcircles @steve @evan no one is taking ownership of a grey area that needs a massive amount of work to make less grey. I wish there would be a team, regardless of their official status, that would work on standards for the fediverse without it being mastodon or otherwise prioritizing own interest over standards.
Evan Prodromou
Steve Bate
@smallcircles @evan Ah, thanks. I see now it's not explicitly required by the process meta-FEP. I had a different impression based on related discussions on SocialHub. So the FEP process allows the FEP discussions to happen anywhere: SocialHub, the FEP issue comments, the SocialCG mailing list, Matrix, here, any combination of these, ... good to know. 😉
🫧 socialcoding..
I feel that it is important that #SocialHub does not assert authority. As a dev community on #ActivityPub it should be an attractive place to be part of and interact with others. That's all. So it is just one hub in the decentralized ecosystem.
We seek collab with other communities, and have a liaison with the #SocialCG.
We facilitate the #FEP Process, but the process itself stands on its own.
So parentheses in 3-stage Standards Process: Ecosystem --> FEP (SocialHub) --> W3C.
🫧 socialcoding..
It's not required, just part of the default procedure. An author that submits a #FEP can just as well choose to collect feedback in other channels, update insights on the tracking issue, and improve the text with PR's without hitting up the #SocialHub forum.
A decentralized ecosystem will evolve in many different ways. The bottom-up Standards Process needs good procedures and see them popularized, so they become natural. There's much to improve, both in FEP Process and also #W3C.
Steve Bate
@smallcircles @evan I've already discussed it on SocialHub. I personally have benefited greatly from seeing W3C and Mastodon discussions about issues in the issue comments (same for many other projects). But that is a tangent. My point is that SocialHub is a required element of the current FEP process. (CORRECTION: SocialHub is not explicitly required. It's just a strongly recommended convention. FEP discussions can officially happen anywhere.)
🫧 socialcoding..
Valid concern, might be discussed, for time being, on SocialHub/FEP.
As I see it, its not different than any other boundaries that having multiple tools always throw up. E.g. the SocialCG / W3C orgs, their various repo's and the mailing list.
A forum, esp. @Discourse is very well-suited to long-form discussion and has way more functionality to organize than an issue tracker.
Looking at "busy" trackers, eg. Mastodon I'm glad not having to deal with that. And they have forum too.
Steve Bate
@smallcircles @evan One of my concerns about the FEP process is that it is actually too tightly coupled to SocialHub for the purpose of FEP discussions. It's natural to comment on an FEP "issue" in the issue tracker. The current approach means the discussion is sometimes fragmented between SocialHub and Codeberg. I think SocialHub is very valuable. I'm just not convinced this is the best way to use it for FEPs.
🫧 socialcoding..
@evan indeed. The SocialHub is just a default discussion place and not required in the process, yet discussing there ensures it reaches a community with many devs active in AS/AP and knowledge is also conserved in one place for the longer term.
This in contrast to huge amounts of insights being passed around in toots in numerous exchanges between people.
The 3-stage Standards Process should encourage discussion on SocialHub for FEP's, just as it should encourage further follow-up towards W3C.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.