I just read your docs on handling C2S collections, and just thought to drop you the link to the SeekItem draft that @evan has created. Dunno if its relevant to you, so just FYI:
swicg.github.ioSeek Item
Replying to @smallcircles@social.coop
@smallcircles my personal feeling towards specifications that introduce bespoke APIs for a one purpose functionality that can be already done is that they're misplaced effort.
@evan, or the SWICG, have a tendency to ignore previous art when they come up with these random specifications. That document of mine you linked to was actually turned into FEP-6606, so it's as visible as anything would be to the SWICG.
I already argued enough about the media upload end point that I don't have the energy to drop what I'm working on and jump on the mailing list and IRC to draft and present a coherent case for why I think they are bad.
Replying to @mariusor@metalhead.club
Oh, it is great that that is turned into a #FEP. Thank you!
Other than that - even though I have thoughts on the current standardization process and the role of the SWICG (see quote) - I don't think your critique of SWICG is fair in this case. The SeekItem is still just an unofficial draft by Evan, as 'random' as anything that happens in the developer ecosystem, and the SWICG is explicitly seeking feedback from the AP developer community to improve these specs so they gain broader buy-in and adoption. In that regard it is no different than proposing a FEP, I guess?
But I understand your point about energy and all that. Am running on low-bat myself in that regard :(
🫧 Social coding commons@smallcircles@social.coopHaving looked in more detail at the #SWICG document. That's not the 3-stage process I advocated for at the time, and I agree with you: It will not work. Such top-down formal ceremony just does not fit a grassroots ecosystem.
Generally speaking I don't think #W3C as a standardization body is up to the task of being a good host for the ActivityPub specification. It is a) not organized for our environment, and b) only takes care of the technical aspects. Our social media landscape has a huge social component, and this is wholly underrepresented in our app-centric fediverse, where people are merely "users" and #FOSS culture is the only driving force.
Today I think SWICG should focus on the 'Protocol implementer' stakeholder: How can they offer compliant #ActivityPub protocol implementations.
Then #FEP can focus on the 'Solution developer', relieved from the plumbing: What interoperable designs do they use to serve the needs of participants on the social network.
Replying to @smallcircles@social.coop
@smallcircles I might be off base here, but from where I'm standing, when they embark on their roles, their primary mission becomes to keep track of what's happening in the community.
It's their job to read all the FEPs that are relevant to a particular piece of functionality they're discussing. Sure, the FEPs might not be useful, but IMHO they need to include references that they did their due diligence.
As a community member I can offer my thoughts if asked for, but I think it's unreasonable that it's me that needs to keep track of everything they're working on, and take time out of my own stuff to author feedback unprompted.
Replying to @mariusor@metalhead.club
> Their primary mission becomes to keep track of what's happening in the community.
I agree on that, partially. It goes both ways, to the benefit of everyone. The folks at the SWICG are also just volunteering their time as participants in the same developer ecosystem. A bit of giving and a bit of taking is needed.
That said, we have a bottom-up standardization process, not a top-down hyper-formal one that is more appropriate for creating corporate industry standards. And the SWICG tends to the latter, which is imho a flaw and mistake similar to how Solid project operates, and fails to reach their community.
Fediverse evolution is community-driven first and foremost.
Replying to @smallcircles@social.coop
> The folks at the SWICG are also just volunteering their time
Oh, for some reason, I thought they get paid for their time. Apologies for being so blunt then...
Replying to @mariusor@metalhead.club
@mariusor @smallcircles Hi! I'm aware of your FEP. It's too big and it does too much. There's no way to declare support for the whole thing or only part. And it does id string manipulation in an ecosystem where ids are otherwise opaque.
SeekItem allows declaring support for one feature for one collection. It supports a few important user stories, like membership check and last-seen activity, with a very AP-native API.
Replying to @evan@cosocial.ca
@mariusor @smallcircles finally, if you want FEPs to be considered for W3C standards, you have to submit them under the SocialCG contributor license agreement. The FEP system has a copyright grant but not a patent license like the CLA.
Replying to @evan@cosocial.ca
@evan it's a sad situation when valuable content released in good faith as public domain is not suitable for inclusion. Requiring people to sign a CLA is a bit of a slap in the face in my opinion.
Replying to @mariusor@metalhead.club
@mariusor @smallcircles It's nothing personal.
Standards organisations like the IETF and W3C have patent-free standards policies. Which is why you can use ActivityPub without paying me ten cents a message!
https://www.w3.org/policies/patent-policy/
I think given the potential downsides, it's really worthwhile and relatively lightweight. The CLA is pretty short and straightforward:
Replying to @evan@cosocial.ca
I think CC0 is a great license, but it's only for copyright (reproducing the text of the FEP), not for patents (implementing the process in the FEP).