• smallcircles@lemmy.mlOPM
    link
    fedilink
    arrow-up
    1
    ·
    3 years ago

    Yes, this is a good point. Though the issue you raise is a more universal one. In a future fediverse there’ll be more and more different application types that are interoperating in all kinds of ways. The question of ‘which client supports what?’ becomes much more prominent then. Potentially very confusing for fedizens, unless specifically addressed.

    On the one hand this can be done via standardization or strong consensus on what ActivityPub extensions to use, and Capability Negotiation, and on the other hand - on the client side - a move to more “universal clients” (supporting the Client-to-Server part of the AP spec, and NOT the Mastodon API which can never keep up with all this) is a way forward.

    Offering an intuitive UX for that will be challenging. You might say that with all its different apps, the fediverse represents a kind of ‘cloud-based-appstore’, but that doesn’t cut it. I think at this time the fedi will become more service-oriented, while the client devices may become more task-oriented. See also: From silo-first to task-oriented app design.

    • poVoq@lemmy.ml
      link
      fedilink
      arrow-up
      4
      ·
      edit-2
      3 years ago

      I never quite understood the obsession many people seem to have with apps. Especially nowadays when many apps are more or less websites wrapped in react-native or such anyways.

      Alternative front-ends like Pleroma is doing, or maybe a multi-account PWA client like https://pinafore.social/ seem the better way forward.

      So I kind of agree that server fediverse software should probably more cleanly seperate the front-end from the back-end and that will also help with apps, but the possibility for communities to add or customize their own web front-end is probably the more important aspect of it.