W3C SWICG April 2023 Survey Results

Standards work on the core specs: known issues that are non-breaking ...

Multiple choice

1. 7 (50%): ... should be fixed some time, but it's not urgent.
2. 4 (29%): ... should be fixed asap.
3. 3 (21%): ... are not serious enough to warrant work beyond what has been done already.
4. 0 (0%): No response

On the question of "Standards work on the core specs: known issues that are non-breaking" I personally ...

Multiple choice

1. 6 (43%): ... am willing and able to do a little work.
2. 6 (43%): ... am unable/unwilling/unqualified to work on.
3. 1 (7%): No response
4. 1 (7%): ... am willing and able to spend a significant amount of work.

Any comments on the question of "Standards work on the core specs: known issues that are non-breaking"

Long text

• 8 (57%): No response
• It's Evan, co-author of the main specs. I think there are a lot of possible extensions to the core specs, and there are Errata that should be noted, but I don't anticipate making additional changes to the specs themselves.
• Depends on the scope of breaking so it's hard to answer this question!
• apply occams razor when releasing standards and concentrate on core aspects, not hypothetical fringe cases. And always make them actionable by providing a compliance check – be it a reference implementation, a validator or a test suite.
• Can an example (or a list of examples) of these non-breaking changes be shared out?
• My understanding is that all of the known issues are small non normative example issues or similar
• I think something that is very important to fix is authentication of S2S traffic. Currently we use HTTP signatures because that is what Mastodon uses and everyone wants to be compatible with Mastodon. While it is not a breaking change in the sense that it is not specified in the ActivityPub TR, it is still a breaking change for implementations. The way forward here is difficult, and while of course not the focus of a standardization group, "ossification" of protocols like this should not be left out of consideration. It is definitely a concern that ActivityPub will age poorly.

Standards work on the core specs: known issues that may be breaking ...

Multiple choice

1. 8 (57%): ... should be fixed some time, but it's not urgent.
2. 4 (29%): ... should be fixed asap.
3. 1 (7%): No response
4. 1 (7%): ... are not serious enough to warrant work beyond what has been done already.

On the question of "Standards work on the core specs: known issues that may be breaking" I personally ...

Multiple choice

1. 5 (36%): ... am unable/unwilling/unqualified to work on.
2. 4 (29%): ... am willing and able to do a little work.
3. 3 (21%): ... am willing and able to spend a significant amount of work.
4. 2 (14%): No response

Any comments on the question of "Standards work on the core specs: known issues that may be breaking"

Long text

• 9 (64%): No response
• I'm not aware of issues that are breaking.
• Breaking or non-breaking may be hard to tell apart.
• I'd like to learn more about what's effectively broken.
• I do not think there is consensus among current implementers significant enough to warrant breaking change at this time. The only exception I can think of is Reply Approval
• I'm not aware of such issues.

Standards work on the core spec to reduce certain loads ...

Multiple choice

1. 7 (50%): ... should be worked on some time, but it's not urgent.
2. 4 (29%): ... is not important enough to warrant work beyond what has been done already.
3. 3 (21%): ... should be worked on asap.
4. 0 (0%): No response

On the question of "Standards work on the core spec to reduce certain loads" I personally ...

Multiple choice

1. 6 (43%): ... am unable/unwilling/unqualified to work on.
2. 5 (36%): ... am willing and able to do a little work.
3. 2 (14%): ... am willing and able to spend a significant amount of work.
4. 1 (7%): No response

Comments on the question of "Standards work on the core spec to reduce certain loads"

Long text

• 9 (64%): No response
• I'm kind of confused why you're asking. I don't think this is a question the SWICG has the choice to answer; these docs were already published a few years ago.
• what are 'certain loads'?
• Anything that makes this space into a more equitable and communal-driven environment and allows for standards to be worked on in a living fashion is something I'm in favor of.
• Not sure what this refers to.
• I do not currently see issues about this. The biggest "problem" is that we should have smaller instances (mastodon.social and mastodon.online are far too big). And since not everybody wants to talk to everybody else, there will not necessarily be huge loads. Monopolies are bad. Something that I think might be interesting is the "slashdotting" of someone posting a link and many instances going to fetch a link preview, but that is an implementation detail that I believe out of scope for SWICG.

With respect to the client-to-server spec:

Multiple choice

1. 7 (50%): We need to first figure out why developers have not implemented it more frequently than it has been.
2. 4 (29%): I believe technical specification work is needed.
3. 2 (14%): I believe no work is currently necessary.
4. 1 (7%): The Mastodon client-to-server API should be officially standardized, as it is widely implemented.
5. 0 (0%): No response

On the subject of the client-to-server spec, I personally ...

Multiple choice

1. 6 (43%): .... am unable/unwilling/unqualified to work on.
2. 4 (29%): ... am willing and able to spend a little work.
3. 3 (21%): ... am willing and able to spend a significant amount of work.
4. 1 (7%): No response

Comments on the subject of the client-to-server spec

Long text

• 8 (57%): No response
• It needs more implementations.
• leverage existing specs, not drafts (header signing, sigh) and refer to them explicitly. Don't usually spec what is already spec'd elsewhere. Maybe don't spec usecases.
• Making the C2S spec more concrete will allow for more non-implementation-specific systems to grow and that's what we need.
• If we want fediverse instances to just work with the vast majority of clients regardless of the type of instance (e.g. mastodon, pixelfed, lemmy) then having an API that supports common features that are above and beyond what AP does is needed. The Mastodon API is a good starting point and then possibly coming up with W3C specs for features under the hood would be a good thing.
• Needs more implementation experience/exploration before standardization.
• I think just standardizing what Mastodon does would not be the right thing to do... ... because it would ignore even taking a look at what may be possible, especially with looking on querying data: SPARQL, GraphQL, etc. might all be interesting in some capacity. The question is which is a broad enough thing to use. ... because it focuses on microblogging and ActivityPub is more than that. Mastodon already has a huge de-facto monopoly over ActivityPub implementation and interpretation, let's not make it even bigger.

Standards work on significant extensions to the core spec with respect to improved security and privacy ...

Multiple choice

1. 7 (50%): ... should be worked on asap.
2. 6 (43%): ... should be worked on some time, but it's not urgent.
3. 1 (7%): ... are not important enough to warrant work beyond what has been done already.
4. 0 (0%): No response
5. 0 (0%): ... should not be worked on at all.

On the question of "Standards work on significant extensions to the core spec with respect to improved security and privacy", I personally ...

Multiple choice

1. 5 (36%): ... am willing and able to spend a significant amount of work.
2. 4 (29%): .... am unable/unwilling/unqualified to work on.
3. 3 (21%): ... am willing and able to spend a little work.
4. 2 (14%): No response

Comments on the question of "Standards work on significant extensions to the core spec with respect to improved security and privacy"

Long text

• 8 (57%): No response
• Especially the use of encrypted MIME types in the content of a Note or Article.
• do it thorough, not in haste. Be clear about it, however. Don't make bold promises you may break.
• We need to get end-to-end encryption working either as part of AP core or as a official extension to the spec.
• GDPR concepts such as "what do you know about me" and "delete everything you know about me" should have proposed implementation strategies that all fediverse servers should be compliant with. Not just GDPR, but the least common denominator of all country and state level privacy laws.
• Needs more implementor outreach and experimentation before standardization
• As mentioned before I think the most important point here is S2S authentication. Although the choice to not prescribe a particular authentication method in the TR is good insofar as I think there was no solid method at the time the TR was written, maybe now that can be reconsidered.

Standards work on significant extensions to the core spec to express terms under which content is provided ...

Multiple choice

1. 4 (29%): ... should be worked on asap.
2. 4 (29%): ... should be worked on some time, but it's not urgent.
3. 4 (29%): ... are not important enough to warrant work beyond what has been done already.
4. 2 (14%): .... should not be worked on at all.
5. 0 (0%): No response

On the question of "significant extensions to the core spec to express terms under which content is provided", I personally ...

Multiple choice

1. 9 (64%): ... am unable/unwilling/unqualified to work on.
2. 3 (21%): ... am willing and able to spend a significant amount of work.
3. 2 (14%): ... am willing and able to spend a little work.
4. 0 (0%): No response

Comments on the question of "significant extensions to the core spec to express terms under which content is provided"

Long text

• 9 (64%): No response
• There's a great Creative Commons vocabulary https://creativecommons.org/ns that would make a good start.
• once published you have to trust the recipients to not leak your content. There is no way to unpublish. In real life you cannot unspeak either. So the terms express a wish and are a legal lever to use in dispute but do not affect facts. In doubt rather do not provide the content at all.
• Anything that provides more control over how content is shared, introducing a true sense of consent to the Web and allowing people to retroactively adjust access is important to me.
• I know this is a personal wishlist item for you but I do not think machine readable licensing is a good idea
• It should, at least, allow us to express 1) licensed under Creative Commons, 2) Do not index for search purposes, 3) No use outside of ActivityPub-enabled software.

A single-document minimal, but full-stack Fediverse interop profile...

Multiple choice

1. 5 (36%): ... should be worked on asap.
2. 5 (36%): ... should be worked on some time, but it's not urgent.
3. 3 (21%): ... should not be worked on at all.
4. 1 (7%): ... is not important enough to warrant work beyond what has been done already.
5. 0 (0%): No response

On the question of a "single-document minimal, but full-stack Fediverse interop profile", I personally ...

Multiple choice

1. 7 (50%): ... am unable/unwilling/unqualified to work on.
2. 5 (36%): ... am willing and able to spend a little work.
3. 1 (7%): No response
4. 1 (7%): ... am willing and able to spend a significant amount of work.

Comments on the question of "single-document minimal, but full-stack Fediverse interop profile"

Long text

• 9 (64%): No response
• No.
• Though I’m not qualified to work in any of the standards efforts, I DO want to help out, and I believe that I can participate in the work to develop an interop profile.
• it may be linked and refer to other standards (rfc/w3c). First the goals and scope have to be fixed.
• We have too many different varieties of UX/different types of apps to make a single document profile feasible.
• This is probably something better done by the developer community and not the standardization group. There may of course be overlap in people between these groups but the focus for e.g. meetings about standardization should keep a very clear focus which does not involve these "profiles".

Other than a basic Fediverse interop profile, other profiles ...

Multiple choice

1. 7 (50%): .... should be worked on some time, but it's not urgent.
2. 5 (36%): ... are not important enough to warrant work beyond what has been done already.
3. 2 (14%): ... should be worked on asap.
4. 0 (0%): No response
5. 0 (0%): ... should not be worked on at all.

If you answered that some other profile(s) should be worked on, please list which profiles

Long text

• 11 (79%): No response
• What other profiles could there be? The fediverse is very big.
• I’m not sure what this means but I’m all for it. The easier we can make interop, the more powerful the Fediverse becomes.

On the question of other profiles, I personally ...

Multiple choice

1. 8 (57%): ... am unable/unwilling/unqualified to work on.
2. 5 (36%): ... am willing and able to spend a little work.
3. 1 (7%): No response
4. 0 (0%): ... am willing and able to spend a significant amount of work.

Comments on the question of other profiles

Long text

• 13 (93%): No response
• This seems dumb.

A set of web "intent buttons" for Like, Follow, Post etc that work across sites ...

Multiple choice

1. 6 (43%): ... should be worked on asap.
2. 5 (36%): ... should be worked on some time, but it's not urgent.
3. 2 (14%): ... are not important enough to warrant work beyond what has been done already.
4. 1 (7%): ... should not be worked on at all.
5. 0 (0%): No response

On the question of web intent buttons, I personally ...

Multiple choice

1. 7 (50%): ... am unable/unwilling/unqualified to work on.
2. 5 (36%): ... am willing and able to spend a little work.
3. 1 (7%): No response
4. 1 (7%): ... am willing and able to spend a signficant amount of work.

Comments on the question of web intent buttons

Long text

• 7 (50%): No response
• I like these.
• i don't unterstand what you mean by this. I think the AP Protocol is clear enought
• I’m not sure how to tackle the technical challenges in this one, but I’m happy to help out however I can
• The IndieWeb has some prior art to this that can work today https://indieweb.org/webactions that leaned a bit on what was done with existing networks.
• Making this work will help TREMENDOUSLY to get mainstream users to enjoy the fediverse as much as they do interacting with walled garden social networks.
• maybe outside the AP spec family
• I think this is gimmicky and unnecessary.

A design for search that meets the requirements of all relevant parties and points of view ...

Multiple choice

1. 6 (43%): ... should be worked on some time, but it's not urgent.
2. 4 (29%): ... should not be worked on at all.
3. 3 (21%): ... should be worked on asap.
4. 1 (7%): No response
5. 0 (0%): ... is not important enough to warrant work beyond what has been done already.

On the question of a design for search that meets the requirements of all relevant parties and points of view, I personally ...

Multiple choice

1. 8 (57%): ... am unable/unwilling/unqualified to work on.
2. 3 (21%): ... am willing and able to spend a little work.
3. 2 (14%): ... am willing and able to spend a significant amount of work.
4. 1 (7%): No response

Comments on the question of a design for search that meets the requirements of all relevant parties and points of view

Long text

• 7 (50%): No response
• Search IS coming to the Fediverse. If the community does not fill the gap on its own terms, Simone else surely will on theirs.
• should be done separate.
• Search requires consent if it aims to collect a lot of information. I think the privacy work needs to be done before we explore search.
• Discovery for mainstream users again is important for fediverse adoption.
• more non-technical than technical, and probably not a job for a standards body
• While discoverability in general should be worked on search in specific is an antipattern and fundamentally goes against a privacy focused and human focused design in favor of incentivizing SEO spam.
• Especially until the terms under which content is provided have been cleared up, this is probably impossible to work on.

Best practices for content propagation (eg propagation of "Likes") ...

Multiple choice

1. 7 (50%): ... should be worked on some time, but it's not urgent.
2. 2 (14%): ... should be worked on asap.
3. 2 (14%): ... are not important enough to warrant work beyond what has been done already.
4. 2 (14%): ... should not be worked on at all.
5. 1 (7%): No response

On the question of best practices for content propagation, I personally ...

Multiple choice

1. 7 (50%): ... am willing and able to spend a little work.
2. 6 (43%): ... am unable/unwilling/unqualified to work on.
3. 1 (7%): No response
4. 0 (0%): ... am willing and able to spend a significant amount of work.

Comments on the question of best practices for content propagation

Long text

• 8 (57%): No response
• This seems to fall into the general category of interop.
• and should consider human affairs like mental health, fomo, explicitly exclude dark patterns and have evidence-feedback.
• When it comes to Webmentions and WebSub, logic that either works already and well or also powers a lot of subscription logic on the Web, we can use some of those ideas or either work in a pluggable system for it to allow transparent bridging from other services.
• ???
• Individual projects should be allowed to make their own decisions with respect to content propagation.
• As I already said on the mailing list, I think this is an inherent issue with distributed networks and I also do not see why it is necessary that everything should always be in sync.

Improved identity management across the Fediverse ...

Multiple choice

1. 7 (50%): ... should be worked on some time, but it's not urgent.
2. 5 (36%): ... should be worked on asap.
3. 2 (14%): ... should not be worked on at all.
4. 0 (0%): No response
5. 0 (0%): ... are not important enough to warrant work beyond what has been done already.

On the question of improved identity management across the Fediverse, I personally ...

Multiple choice

1. 7 (50%): ... am willing and able to spend a little work.
2. 4 (29%): ... am unable/unwilling/unqualified to work on.
3. 2 (14%): ... am willing and able to spend a significant amount of work.
4. 1 (7%): No response

Comments on the question of improved identity management across the Fediverse

Long text

• 8 (57%): No response
• Our identities are great. The people who don't like them are Blockchain grifters.
• please let's clarify what identity is in the first place. Maybe some breaks and friction is desired and protects vulnerable participants.
• Identity disassociated from the State and from a platform is the bit that'd allow the fediverse to take off more effectively.
• There should be some sort of process by which identity verification can occur amongst "trusted" instances.
• Not sure what this means. Distributed identities? Not sure how identities are separate from any other form of distributed vs federated content. ActivityPub is a federated system, I think it might be possible to build distributed systems "underneath" ActivityPub but I personally am uninterested in working on them.
• There is preexisting work about this, e.g. nomadic identities and Decentralized Identifiers (DID) that should be taken into account or perhaps linked into the ActivityPub TR in some way.

Attract more participants

Multiple choice

1. 7 (50%): ... should be worked on some time, but it's not urgent.
2. 4 (29%): ... should be worked on asap.
3. 1 (7%): No response
4. 1 (7%): ... is not important enough to warrant work beyond what has been done already.
5. 1 (7%): ... should not be worked on at all.

On the question of attracting more participants, I personally ...

Multiple choice

1. 6 (43%): ... am unable/unwilling/unqualified to work on.
2. 5 (36%): ... am willing and able to spend a little work.
3. 2 (14%): ... am willing and able to spend a significant amount of work.
4. 1 (7%): No response

Comments on the question of attracting more participants

Long text

• 9 (64%): No response
• consider sovereignty of the participants – really enable them to operate their own cause. For decades. And not have to subjugate to mini-Muskbergs or exhaust selfless operators.
• I do a lot of critique and can hold events if it's meant to talk about specific parts of AP or the fediverse that need work.
• This is outside of the scope of the SWICG except insofar as it encompasses outreach to existing implementers with significant usage. The last iteration of the community group spent more time on outreach then any technical initiative and I think that was a major mistake.
• It would be nice if people who want to work on ActivityPub have a good feeling for "how the fediverse works". E.g. it feels a bit weird when people who have recently switched over from Twitter now want to bring over Twitter things to the Fediverse "because Twitter does it so I want it".
• I guess I've been working on this for a bit, e.g. by bringing FediForum attendees to a meeting.

What other work do you think is crucial for Fediverse success at this point that can be performed at the W3C and that this survey does not ask about?

Long text

• 9 (64%): No response
• Better validators.
• Increase the possibility for user mobility. Mastodon has some form on it but nothing is standardiced. And it only works if the home server is still running. To implement some sort of distributed adress network would be great
• coach or incubate research and consulting of mental health and sustainability issues.
• Include the Mastodon developers!
• Moderation is always an important topic. I am not sure if more work is needed in this area as I do not personally have any experience with moderating an instance.

What other work do you think is crucial for Fediverse success at this point that, however, cannot easily be performed in the context of the W3C social activities? Where should it be performed?

Long text

• 9 (64%): No response
• Staying focused and in task will be key.
• community building and long-term reliability.
• I think communities need to hold more open forums about what things they'd like to see in the fediverse and learn about what changes are coming down the pipeline.
• How do we prevent single implementations from gaining (or keeping) a monopoly on how the ActivityPub TR is to be interpreted and/or implemented? Or in other words, how would it be possible to establish a long term more democratic approach to interpretation?
• Think through how embrace-extend-extinguish strategies might be attempted, and how exactly we defend against them. Vertical use case work (e.g. what needs to happens so the Fediverse works really well for news organizations)

Your name (same as you use on the SWICG mailing list)

Short answer

• 0 (0%): No response
• Evan Prodromou
• Darius Kazemi
• eest9
• Ben Pate
• Marcus Rohrmoser
• Manton Reece
• Jacky Alcine
• Sean O'Brien
• Greg Scallan
• Bob Wyman
• Ryan Barrett
• .
• Johann Galle
• Johannes Ernst

Your e-mail address (same as you use on the SWICG mailing list)

Short answer

• 0 (0%): No response
• evan@prodromou.name
• darius.kazemi@gmail.com
• eest9@posteo.eu
• ben@pate.org
• me+swicg@mro.name
• manton@micro.blog
• yo@jacky.wtf
• sean.obrien@yale.edu
• greg@flipboard.com
• bob@wyman.us
• w3c@ryanb.org
• .
• johann@qwertqwefsday.eu
• Johannes.Ernst@gmail.com