Re: Updated wish list

čt 6. 4. 2023 v 0:53 odesílatel Johannes Ernst <johannes.ernst@gmail.com>
napsal:

> Based on the discussion in the meeting last week, as well as in other
> FediForum sessions and other conversations, here’s a much expanded version
> of the “Fediverse technical Christmas wish list” (or such).
>
> This can easily keep a horde of people in several distinct working groups
> busy for a few years :-) So we need to prioritize.
>
> Does this group have a preferred tool for surveys of the members here? (If
> not, I can volunteer self-hosted Nextcloud “forms” which we just set up for
> FediForum attendees surveys anyway.)
>
> (On the web at https://reb00ted.org/tech/20230405-fediverse-wishlist/ .)
>
> —
> Standards maintenance work on the core specificationsFixes to the the
> core spec
>
>    - According to reports, ActivityPub as-is is incompatible with common
>    shared hosting environments (e.g. typical WordPress host), as it requires
>    HTTP content negotiation.
>    - Issues backlog
>
>
Regarding "fixes to the core spec" they should be divided into non breaking
changes (1.x) and breaking changes (2.x) with some grey area in between.
For example, fixing the vocabulary related issues at the w3c could be
viewed as a breaking change, yet no one will notice if they were not using
it and it was already broken.

Open issue from 2019: https://github.com/w3c/activitystreams/pull/504
Open issue from 2017: https://github.com/w3c/activitystreams/issues/416

These kind of fixes may go in a 1.x type branch.  But they are taking a
long time to fix in the w3c repo.

A 2.0 spec would have to have a high commitment to backwards compatibility,
since activity pub is already in use.  Though in a sense mastodon (Mastodon
Pub) might have diverged a bit already.  Maybe 2.0 can bring things back
together.

It might be worth documenting what is already in use for the large
providers.  Bearing in mind that when AP 1.0 was created even mastodon
didnt exist.  As it is 5 years old now, and with millions of users, quite a
lot has been learnt.

> A design to reduce certain loads
>
>    - Reduce protocol chattiness
>    - Fan-out
>    - Video
>    - (Not my area of expertise, so I don’t have details)
>
> Decide on the future of ActivityPub Client-to-Server
>
>    - Split the C2S spec from the S2S spec?
>    - Standardize the Mastodon API instead?
>    - Invest in convincing developers to implement it?
>
> Significant extensions of the core specifications with a view on
> standardizing themImproved security and privacy
>
>    - Signed content
>    - Private messages
>
> A standardized way to express terms under which content is provided
>
>    - As I understand it, Bob Wyman calls that a Rights Expression Language
>    - This probably should start with a use case collection
>
> ProfilesA single-document basic [Fediverse] interop spec, ie.
>
>    - when I have written code for everything it says, my code will
>    interoperate in some basic fashion with all other software that has
>    implemented this document
>    - no need to consult or understand other implementations
>    - may be quite basic, e.g. text content only, only a minimal set of
>    activity types
>    - enables implementors to have a “MVP”-style interop at
>    lowest-possible engineering effort (including the time required to
>    read/understand the specs!)
>    - This could be done as a “minimal profile” of a stack that contains a
>    subset of AP [ActivityPub], AS [ActivityStreams], and Webfinger
>
> Other profiles for specific use cases
>
>    - E.g. propagation of event / calendar invites / RSVPs
>
> Documentation and testA test suite for the minimal profile
>
>    - suitable to add to automated test suites
>    - over time, this test suite can grow beyond the minimal profile
>
> Documented behavior of leading ActivityPub implementations
>
>    - What subset of the spec does each implement
>    - What extensions does it implement, and which are required
>    - Document the “folk wisdom” how to interact with a given
>    implementation, so not every new developer has to learn everything from
>    scratch
>    - Get out of “trial and error mode” when attempting to interoperate
>    with another ActivityPub implementation
>
> A branding program for products that have passed the test suite
>
>    - As an implementor, you get to put the sticker on your product.
>    - In particular, in the places in the product where users “connect” to
>    other servers in the Fediverse, like “Visa” is displayed at the POS terminal
>    - I believe this will become critical if/when larger orgs with
>    potentially different value systems connect to the Fediverse
>
> JSON-LD conformance
>
>    - Tests to make sure implementations are JSON-LD conformant
>
> User expectations and usability across the FediverseA set of web “intent
> buttons” for Like, Follow, Post, etc that work across sites
>
>    - like they exist for centralized social media
>    - as easy to use for the user
>    - we can argue how this can be accomplished technically. I have
>    opinions, but for this wish list, they are immaterial, as long as I get
>    those buttons :-)
>
> A design for search that meets the requirements of all relevant parties
> and points of view
>
>    - This is probably far less a technical problem than one of successful
>    communication
>
> Best practices for content propagation
>
>    - E.g. resolve the “It has 5 likes here but 10 over there” issue and
>    related.
>
> Improved identity management across the Fediverse
>
>    - Easy-to-use single-sign-on across servers. Use case: I use several
>    apps for different content types (like micro blog and video). Bonus: they
>    all post from the same identifier
>    - Easy-to-use persona management. Use case: I have a personal and a
>    work account, bonus if they can be on the same server
>    - Identifiers not tied to the domain name system
>
> Attract more participants
>
>    - Get major implementors involved (e.g. Mastodon)
>    - Make the place where technical work is done welcome and the work
>    pleasant
>
>