FEP-a4ed: Promotion of products and services #340

silverpill commented 2024年06月22日 23:29:50 +02:00

Objectives:

• Prevent spam.
• Keep the FEP process fair.
• Ensure alignment of submissions with the stated goal of the FEP process: "interoperability and well-being of diverse services, applications and communities"

This change was initially proposed in #330 by @bumblefudge. I adjusted it a bit and removed the word "commercial". Even if "XYZ" is not a commercial product, I think it is clear that FEP-a59a: Everyone should use XYZ would not be appropriate.

Objectives: - Prevent spam. - Keep the FEP process fair. - Ensure alignment of submissions with the stated goal of the FEP process: "interoperability and well-being of diverse services, applications and communities" This change was initially proposed in https://codeberg.org/fediverse/fep/pulls/330 by @bumblefudge. I adjusted it a bit and removed the word "commercial". Even if "XYZ" is not a commercial product, I think it is clear that `FEP-a59a: Everyone should use XYZ` would not be appropriate.

bumblefudge commented 2024年06月24日 09:09:34 +02:00

Is an API a service, or does everyone using Mastodon's API instead of the community-generated and W3C-goverened C2S one promote Mastodon's adoption and dominance of the market? Is DNS a service? Is a FEP about Nostr interop or Bluesky interop promoting Nostr or Bluesky? I'm a little worried that you can't ban "promotion" without limiting scope too much...

Is [an API](https://codeberg.org/fediverse/fep/src/branch/main/fep/d8c2/fep-d8c2.md) a service, or does everyone using Mastodon's API instead of the community-generated and W3C-goverened C2S one promote Mastodon's adoption and dominance of the market? Is [DNS](https://codeberg.org/fediverse/fep/src/branch/main/fep/612d/fep-612d.md) a service? Is a FEP about Nostr interop or Bluesky interop promoting Nostr or Bluesky? I'm a little worried that you can't ban "promotion" without limiting scope too much...

silverpill commented 2024年06月24日 12:59:04 +02:00

Is an API a service

No. OAuth 2.0 is a protocol.

does everyone using Mastodon's API instead of the community-generated and W3C-goverened C2S one promote Mastodon's adoption and dominance of the market

I don't know, maybe a little bit. There are many Mastodon API providers, so a FEP that mentions Mastodon API wouldn't count as "promotion of a specific service".

Is DNS a service

No, DNS is a protocol.

Is a FEP about Nostr interop or Bluesky interop promoting Nostr or Bluesky?

Nostr is a protocol. Bluesky is a product, so it shouldn't be promoted here, but a FEP about Bluesky interop wouldn't necessarily promote it.

>Is an API a service No. OAuth 2.0 is a protocol. >does everyone using Mastodon's API instead of the community-generated and W3C-goverened C2S one promote Mastodon's adoption and dominance of the market I don't know, maybe a little bit. There are many Mastodon API providers, so a FEP that mentions Mastodon API wouldn't count as "promotion of a specific service". >Is DNS a service No, DNS is a protocol. >Is a FEP about Nostr interop or Bluesky interop promoting Nostr or Bluesky? Nostr is a protocol. Bluesky is a product, so it shouldn't be _promoted_ here, but a FEP about Bluesky interop wouldn't necessarily promote it.

silverpill commented 2024年06月24日 13:28:31 +02:00

FEP about Bluesky interop wouldn't necessarily promote it

Here's a practical example: FEP-fffd: Proxy Objects. The author discusses Twitter-to-AcitivityPub bridge there, but it is mentioned as one option among many, and not advocated for.

>FEP about Bluesky interop wouldn't necessarily promote it Here's a practical example: [FEP-fffd: Proxy Objects](https://codeberg.org/fediverse/fep/src/branch/main/fep/fffd/fep-fffd.md). The author discusses Twitter-to-AcitivityPub bridge there, but it is mentioned as one option among many, and not advocated for.

bumblefudge commented 2024年06月24日 16:56:52 +02:00

does everyone using Mastodon's API instead of the community-generated and W3C-goverened C2S one promote Mastodon's adoption and dominance of the market

I don't know, maybe a little bit. There are many Mastodon API providers, so a FEP that mentions Mastodon API wouldn't count as "promotion of a specific service".

Is DNS a service

No, DNS is a protocol.

Sure, but is ICANN a protocol or a service? You don't magically get IPv4 addresses from using a vendor-neutral decentralized protocol, you get them from ICANN. Is every FEP that relies on DNS resolution enshrining a dependency on the monopoly of ICANN?

Is a FEP about Nostr interop or Bluesky interop promoting Nostr or Bluesky?

Nostr is a protocol. Bluesky is a product, so it shouldn't be promoted here, but a FEP about Bluesky interop wouldn't necessarily promote it.

The AT Protocol is not a product. But Bluesky is currently the only service on it-- so is ATP a protocol, or a monopoly?

I don't think the distinction as written gets us very far, it's just kicking down the road the impossible definition of a service or a business.

> > >does everyone using Mastodon's API instead of the community-generated and W3C-goverened C2S one promote Mastodon's adoption and dominance of the market > > I don't know, maybe a little bit. There are many Mastodon API providers, so a FEP that mentions Mastodon API wouldn't count as "promotion of a specific service". > > >Is DNS a service > > No, DNS is a protocol. Sure, but is ICANN a protocol or a service? You don't magically get IPv4 addresses from using a vendor-neutral decentralized protocol, you get them from ICANN. Is every FEP that relies on DNS resolution enshrining a dependency on the monopoly of ICANN? > > >Is a FEP about Nostr interop or Bluesky interop promoting Nostr or Bluesky? > > Nostr is a protocol. Bluesky is a product, so it shouldn't be _promoted_ here, but a FEP about Bluesky interop wouldn't necessarily promote it. The AT Protocol is not a product. But Bluesky is currently the only service on it-- so is ATP a protocol, or a monopoly? I don't think the distinction as written gets us very far, it's just kicking down the road the impossible definition of a service or a business.

silverpill commented 2024年06月24日 19:22:11 +02:00

ICANN is an international non-profit organization with multiple stakeholders, it doesn't look like a product or a service to me. I don't know much about ATP, but it looks like a documentation of Bluesky API.
Anyway, I'm not sure what these increasingly contrived examples have to do with the proposed change. Defining "service" is not impossible, service is simply a specific piece of software that can be accessed over the network. In most cases distinction between products/services and protocols/ideas is very clear, and there is no reason to believe that facilitators will reject FEPs that talk about DNS on the basis of "promotion of ICANN".

ICANN is an international non-profit organization with multiple stakeholders, it doesn't look like a product or a service to me. I don't know much about ATP, but it looks like a documentation of Bluesky API. Anyway, I'm not sure what these increasingly contrived examples have to do with the proposed change. Defining "service" is not impossible, service is simply a specific piece of software that can be accessed over the network. In most cases distinction between products/services and protocols/ideas is very clear, and there is no reason to believe that facilitators will reject FEPs that talk about DNS on the basis of "promotion of ICANN".

tesaguri commented 2024年06月27日 02:02:32 +02:00

I like the overall direction of the change, but I agree that the scope of the restriction has some room for clarification.

ICANN is an international non-profit organization with multiple stakeholders, it doesn't look like a product or a service to me. I don't know much about ATP, but it looks like a documentation of Bluesky API.

Well, I wouldn't be able to say the same about ICANN with a straight face, considering how it virtually intimidates brands and celebrities into reserving .sucks domains before they are squatted by adversaries, how it let Amazon the US-based company, instead of people of the Amazon river basin, monopolize the .amazon TLD, and so on. But I agree that this specific example sounds contrived.

However, I'm a little less convinced of your remark on AT Protocol. Although I'm not familiar with it either, there are at least two independent implementations of the protocol (Bluesky PDS itself (indigo and atproto npm package) and arroba, which Bridgy Fed uses to implement its own PDS), which I think sufficiently demonstrates the protocol's capability to operate a network independent of the Bluesky PDS.

(By the way, the AT Protocol spec is documented separately from the Bluesky API at https://atproto.com/, just in case.)

So, in the example of Bluesky, the protocol and implementation are open (the speci is CC-BY, indigo and atproto npm package is MIT OR Apache-2.0 and Bluesky Social frontend is MIT). Then, what would be the rationale for rejecting ATP, if any?

(I know that the Scope and Objectives section states that The Fediverse includes applications, services and communities using the ActivityPub protocol and other protocols [...]., but let's ignore that for the sake of example. (Also, it only says includes and not "limited to", but I digress.))

I like the overall direction of the change, but I agree that the scope of the restriction has some room for clarification. > ICANN is an international non-profit organization with multiple stakeholders, it doesn't look like a product or a service to me. I don't know much about ATP, but it looks like a documentation of Bluesky API. Well, I wouldn't be able to say the same about ICANN with a straight face, considering how it virtually intimidates brands and celebrities into reserving `.sucks` domains before they are squatted by adversaries, how it let Amazon the US-based company, instead of people of the Amazon river basin, monopolize the `.amazon` TLD, and so on. But I agree that this specific example sounds contrived. However, I'm a little less convinced of your remark on AT Protocol. Although I'm not familiar with it either, there are at least two independent implementations of the protocol (Bluesky PDS itself ([indigo] and [`atproto`] npm package) and [arroba], which [Bridgy Fed uses to implement its own PDS][bridgy-fed-federation]), which I think sufficiently demonstrates the protocol's capability to operate a network independent of the Bluesky PDS. (By the way, the AT Protocol spec is documented separately from the Bluesky API at <https://atproto.com/>, just in case.) So, in the example of Bluesky, the protocol and implementation are open (the speci is CC-BY, indigo and `atproto` npm package is MIT OR Apache-2.0 and Bluesky Social frontend is `MIT`). Then, what would be the rationale for rejecting ATP, if any? (I know that the <q>Scope and Objectives</q> section states that <q>The Fediverse includes applications, services and communities using the ActivityPub protocol and other protocols [...].</q>, but let's ignore that for the sake of example. (Also, it only says <q>includes</q> and not "limited to", but I digress.)) [indigo]: <https://github.com/bluesky-social/indigo> [`atproto`]: <https://github.com/bluesky-social/atproto> [arroba]: <https://arroba.readthedocs.io/> [bridgy-fed-federation]: <https://github.com/snarfed/bridgy-fed/blob/12d41ad4c0a7d45b4af0476a039223985d9d0fa0/FEDERATION.md#bluesky--at-protocol>

silverpill commented 2024年06月27日 13:52:29 +02:00

Multiple implementations doesn't necessarily mean it is a protocol. I followed links you've provided and found dependencies on external services (AppView, Relay, PLC), about which I heard that they are centralized. If that is true, ATProto is not very different from Twitter API, for example.

I'd like to re-iterate that faciliatator's decision should depend on how product/service is presented. FEP-fffd talks about Twitter API, but it doesn't promote it. I agree that we can't define "promotion" or "service" with mathematical precision, but that doesn't mean these concepts are useless. Vendor neutrality is the basis of all standards, and while FEPs are not technically standards, they come pretty close. I assume other RFC-like processes also don't allow promotion of proprietary APIs (I can't find anything like that by scanning XEP titles: https://xmpp.org/extensions/).

Perhaps we should shift focus from promotion to vendor neutrality by re-arranging sentences?

Proposals should describe vendor-neutral solutions, and do not promote any specific product or service.

Multiple implementations doesn't necessarily mean it is a protocol. I followed links you've provided and found dependencies on external services (AppView, Relay, PLC), about which I heard that they are centralized. If that is true, ATProto is not very different from Twitter API, for example. I'd like to re-iterate that faciliatator's decision should depend on how product/service is presented. FEP-fffd talks about Twitter API, but it doesn't promote it. I agree that we can't define "promotion" or "service" with mathematical precision, but that doesn't mean these concepts are useless. Vendor neutrality is the basis of all standards, and while FEPs are not technically standards, they come pretty close. I assume other RFC-like processes also don't allow promotion of proprietary APIs (I can't find anything like that by scanning XEP titles: https://xmpp.org/extensions/). Perhaps we should shift focus from promotion to vendor neutrality by re-arranging sentences? >Proposals should describe vendor-neutral solutions, and do not promote any specific product or service.

bumblefudge commented 2024年07月17日 13:55:46 +02:00

I think the fact the three of us weighing in here can't seem to agree what is a product and what is a commercial enterprise proves my point that such categories are actually way more squishy and less specifiable than meets the eye. they are not pre-existing, natural, or universal categories that exist in the world before software is invented; they always were and always will be political and subjective boundaries.

I think the most recent post in mark nottingham's series of meditations on "neutrality" and "objectivity" in technical standards bears reading here: standards seem, at first glance, to have clear-cut policies against "self-promotion" and "collusion" (they are, after all, anti-trust defense mechanisms), but beneath the surface all kinds of euphemisms and indirect self-promotion and self-dealing still happens, whenever fighting it becomes too impractical or costly to the organization and the rest of its membership. Which is to say, it's worth having some policy, but it's delusional to think a concise policy can be written easily and applied fairly-- it's turtles (and discretion, and attributions of intent, and theories of justice) all the way down.

I think the fact the three of us weighing in here can't seem to agree what is a product and what is a commercial enterprise proves my point that such categories are actually way more squishy and less specifiable than meets the eye. they are not pre-existing, natural, or universal categories that exist in the world before software is invented; they always were and always will be political and subjective boundaries. I think the most [recent post](https://www.mnot.net/blog/2024/07/16/collaborative_standards) in mark nottingham's series of meditations on "neutrality" and "objectivity" in technical standards bears reading here: standards seem, at first glance, to have clear-cut policies against "self-promotion" and "collusion" (they are, after all, anti-trust defense mechanisms), but beneath the surface all kinds of euphemisms and indirect self-promotion and self-dealing still happens, whenever fighting it becomes too impractical or costly to the organization and the rest of its membership. Which is to say, it's worth having some policy, but it's delusional to think a concise policy can be written easily and applied fairly-- it's turtles (and discretion, and attributions of intent, and theories of justice) all the way down.

This pull request can be merged automatically.

You are not authorized to merge this pull request.