Fediverse Enhancement Proposals (FEP) A common place for people to create drafts and follow lightweight rules for documenting technical details for other developers. Also see: https://socialhub.activitypub.rocks
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

fep-f1d5.md 5.7 KiB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132
  1. ---
  2. authors: CJ <cjslep@gmail.com>
  3. status: DRAFT
  4. dateReceived: 2020-12-13
  5. ---
  6. # FEP-f1d5: NodeInfo in Fediverse Software
  7. ## Summary
  8. NodeInfo is a protocol intended to standardize upon a way to provide
  9. server-level metadata to the public. This enables tools and clients to utilize
  10. this metadata to assess server health or facilitate end-users choices about
  11. servers and software to use on the Fediverse.
  12. ## History
  13. NodeInfo was developed prior to the ActivityPub protocol targeted for use by
  14. diaspora, friendica, and redmatrix software [ActivityPub]. Some of the original
  15. protocols it encapsulated include diaspora, pumpio, and gnusocial.
  16. The NodeInfo specification is incredibly strict in its schema, often requiring
  17. regex-validation and a closed set of enumerated possible values. As an objection
  18. to this, the NodeInfo2 fork was created as a form of criticism by removing some
  19. validation of fields and with some logical restructuring of the metadata
  20. [ServiceInfo]. Building off of NodeInfo and NodeInfo2, ServiceInfo was briefly
  21. explored [ServiceInfoRepository].
  22. This FEP does **not** attempt to document the specific protocol details. For
  23. that, see the [NodeInfoRepository] and [NodeInfo2Repository]. It attempts to
  24. clarify the history and identify shortcomings with the current approaches, to
  25. bring context to developers of Fediverse Software.
  26. ## Requirements
  27. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
  28. "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to
  29. be interpreted as described in [RFC-2119].
  30. Fediverse software SHOULD implement NodeInfo [NodeInfoRepository].
  31. ## Caveats
  32. At the time of this FEP's writing, the current objections to the current state
  33. of NodeInfo that have been identified by the community are below. Note that any
  34. technical alternatives identified are meant to be illustrative and not
  35. prescriptive:
  36. * The `software.name` regex is unnecessarily strict. For example, no uppercase
  37. letters, no spaces, no non-English-alphabet, and no special characters besides
  38. hyphen are permitted.
  39. * The `software.version` field is required, which is unnecessarily strict.
  40. Forcibly requiring software to divulge version information is potentially a
  41. security issue.
  42. * The `inbound` and `outbound` elements are specified as a closed set of enums
  43. instead of a simple string. Protocol versioning manifests as renaming, having
  44. to add a new enum, which results in unclear version management.
  45. * The Fediverse software MUST have an `openRegistrations` concept due to it
  46. being required.
  47. * Lacks an extendable method for identifying and versioning other features, such
  48. as HTTP Signatures, webfinger, or OAuth. Whereas the specification is very
  49. strict, the `metadata` is too lax.
  50. * The `usage.users` is not denormalized, such that implementations can provide
  51. custom pairs of `(activity counts, time period in days)` that make sense for
  52. the software.
  53. * The `usage.users` assumes that user identity is tied to a specific instance of
  54. running software. It is unclear how to count `total` users when user identity
  55. is: spread across multiple servers, spread across multiple groups, or present
  56. within multiple collections of users. Multiple software instances could each
  57. have a resonable claim to counting the user as "using" their software, which
  58. globally results users being counted more than once.
  59. * The `usage.users` activity counts likewise assume that user identity is tied
  60. to a specific instance of running software. For the same reasons above, where
  61. the `total` user counts may result in duplicate counts of the same user across
  62. all software running, the activity counts `activeHalfYear` and `activeMonth`
  63. may also result in a globally inflated count.
  64. * The `activeHalfyear` and `activeMonth` are ill-named properties for describing
  65. the time periods of 180 days and 30 days, respectively. A "half of one year"
  66. is 180 days 0% of the time and roughly 182.5 days only 75% of the time. A
  67. month is 30 days only 33% of the time.
  68. * The `localPosts` and `localComments` are not denormalized into pairs of
  69. `(kind, counts)` for software that, for example, hosts audio files, hosts
  70. videos, or software that does not have comments, or does not have posts.
  71. * The `localPosts` and `localComments` are required, which is problematic for
  72. software that does not have comments, or does not have posts.
  73. ## Implementations
  74. ### Servers
  75. This list is not comprehensive:
  76. * Mastodon
  77. * Matrix
  78. * Pleroma
  79. * PeerTube
  80. * WriteFreely
  81. * Friendica
  82. * Diaspora
  83. * PixelFed
  84. * Misskey
  85. * Funkwhale
  86. * Smithereen
  87. * Plume
  88. * GNU Social
  89. * lemmy
  90. * zap
  91. * Socialhome
  92. * epicyon
  93. * apcore
  94. ### Clients
  95. * [The-Federation.Info](https://the-federation.info/)
  96. * [Pod Uptime](https://podupti.me/)
  97. * [Hello Matrix Public Servers](https://www.hello-matrix.net/public_servers.php)
  98. ## References
  99. - [ActivityPub] Christopher Lemmer Webber, Jessica Tallon, [ActivityPub](https://www.w3.org/TR/activitypub/), 2018
  100. - [NodeInfoRepository] Jonne Haß, [jhass/nodeinfo](https://github.com/jhass/nodeinfo), 2014
  101. - [NodeInfo2Repository] Jason Robinson, [jaywink/nodeinfo2](https://github.com/jaywink/nodeinfo2), 2016
  102. - [ServiceInfo] Jason Robinson, [ServiceInfo - specification for service metadata](https://talk.feneas.org/t/serviceinfo-specification-for-service-metadata/99), 2019
  103. - [ServiceInfoRepository] Jason Robinson, [feneas/serviceinfo](https://git.feneas.org/feneas/serviceinfo), 2019
  104. - [RFC-2119] S. Bradner, [Key words for use in RFCs to Indicate Requirement Levels](https://tools.ietf.org/html/rfc2119.html), 1997
  105. ## Copyright
  106. CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
  107. To the extent possible under law, the authors of this Fediverse Enhancement
  108. Proposal have waived all copyright and related or neighboring rights to this
  109. work.