Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse

NodeBB

  1. Home
  2. General Discussion
  3. #ActivityPub is getting its first formal update path since 2018.

#ActivityPub is getting its first formal update path since 2018.

Scheduled Pinned Locked Moved General Discussion
activitypub
44 Posts 15 Posters 7 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • silverpill@mitra.socialS silverpill@mitra.social

    @dimkr I mean implementers of ActivityPub specification. I think if a feature doesn't rise to the level of "most projects should support it", it shouldn't be included in the specification.

    FEPs are a different story, In many cases 2 independent implementations of a FEP is enough.

    D This user is from outside of this forum
    D This user is from outside of this forum
    dimkr@didkey.000090000.xyz
    wrote on last edited by
    #41

    @silverpill I agree, huge parts of the spec don't have enough interoperable implementations to justify them. However, this rule also means it's super hard to 'upstream' a FEP into the spec because it's hard to count implementations that do exactly what the FEP says.

    1 Reply Last reply
    0
    • silverpill@mitra.socialS silverpill@mitra.social

      @evan @julian @slyborg

      The best I can come up with are features that are too complex for small development teams

      This is probably the biggest risk.

      Another risk is changes that prevent the development of important features in the future.

      evan@cosocial.caE This user is from outside of this forum
      evan@cosocial.caE This user is from outside of this forum
      evan@cosocial.ca
      wrote on last edited by
      #42

      @silverpill @julian @slyborg Those are really good. I'm going to see what I can do to collect some of these concerns before we get started with the WG.

      1 Reply Last reply
      0
      • giacomo@snac.tesio.itG This user is from outside of this forum
        giacomo@snac.tesio.itG This user is from outside of this forum
        giacomo@snac.tesio.it
        wrote on last edited by
        #43
        @doctormo@floss.social

        Yet, given major #ActivityPub implementors don't give a shit about #W3C standard, the only way a working group can produce any protocol change is on sound technical merits.

        Otherwise the standard will say irrelevant.

        And on a deeper look, despite the huge limits of #Mastodon gmbh, so far it's still better then W3C.

        @julian@activitypub.space
        1 Reply Last reply
        0
        • tasket@infosec.exchangeT tasket@infosec.exchange

          @julian IMO there's no reason why a web browser should understand where to open fedi links, without having any other type of app properly address those links as well.

          What if someone in an instant messenger or email app sends you a link to fedi content?

          Defining it at the system level (again, as is done with email) removes critical uncertainties.

          Fedi has other big UX issues as well. Celebrities don't like it here because the TL mechanics make them unintentionally annoying... users follow then later mute them because their posts are popular for a while and we have to see them each and every time they're boosted (or manually silence those posts). Allowing the selection of some transparent algorithms could fix this.

          trwnh@mastodon.socialT This user is from outside of this forum
          trwnh@mastodon.socialT This user is from outside of this forum
          trwnh@mastodon.social
          wrote last edited by
          #44

          @tasket@infosec.exchange @julian

          with http: and https: the pattern is not to use a protocol handler but to instead use a content-type handler. a different protocol forks the network, and leads to bad UX when you have custom protocol links being copied into apps that don't understand them. also you end up with multiple links for the same thing, and you have to recognize equivalences wherever there might be any.

          web links have a "type" parameter for this. see firefox for example (pic 1) on SVG or PDF content

          1 Reply Last reply
          0

          Hello! It looks like you're interested in this conversation, but you don't have an account yet.

          Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

          With your input, this post could be even better 💗

          Register Login
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          Powered by NodeBB Contributors
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • World
          • Users
          • Groups