Conversation

Notices

1. Internet Turtle Ⓐ (infernalturtle@gnusocial.no)'s status on Sunday, 28-Jan-2018 11:38:01 EST Internet Turtle Ⓐ
   Are there any technical obstacles to implementing ActivityPub for GNU Social? If I make a bounty for it, is it likely to be taken up?
   1. lnxw48a1 (lnxw48a1@nu.federati.net)'s status on Sunday, 28-Jan-2018 11:43:04 EST lnxw48a1

      in reply to
      @infernalturtle I suspect it is just lack of available developer time.
      1. Internet Turtle Ⓐ (infernalturtle@gnusocial.no)'s status on Sunday, 28-Jan-2018 11:52:47 EST Internet Turtle Ⓐ

         in reply to
         That's what I'm hoping, in that case I would be much more confident putting a bounty up. Never did it before.
   2. Annah (maiyannah@community.highlandarrow.com)'s status on Sunday, 28-Jan-2018 11:49:28 EST Annah

      in reply to
      @infernalturtle Its basically a carbon copy of ostatus anyways, there's nothing of value gained from the time it takes to implement it.  In fact, there are features ostatus has which activitypub lacks (at least in the formal specification)
      1. Internet Turtle Ⓐ (infernalturtle@gnusocial.no)'s status on Sunday, 28-Jan-2018 11:59:37 EST Internet Turtle Ⓐ

         in reply to
         Is that so? I feel like before Mastodon came about, people weren't so negative about it, but maybe there were just fewer people talking about it. I just think it would be nice if Pump.io and GNU social could federate, plus some other applications like GNU Mediagoblin and PeerTube. More applications seem to be moving toward ActivityPub so that's why I think it would be good to support it even if it's not technically superior.
         1. Annah (maiyannah@community.highlandarrow.com)'s status on Sunday, 28-Jan-2018 12:01:57 EST Annah

            in reply to
            @infernalturtle pumpio has it's own protocol, though its supposed to be adopting activitypub I suppose.
            
            Most of the negativity surrounding ActivityPub essentially comes from broken promises.  There's a lot of stuff they said they'd work on or add in that never made it into the approved specification.  In fact, a lot of those features were REQUESTED by people on Mastodon (and elsewhere) to begin with, so I've not actually understood the defensiveness Mastodon has over it (beyond the fact that the W3C has a mastodon instance so I guess you get the ingroup v outgroup dynamic)
            1. Annah (maiyannah@community.highlandarrow.com)'s status on Sunday, 28-Jan-2018 12:03:11 EST Annah

               in reply to
               @infernalturtle Speaking only for myself, I get only so many productive hours in a week, I don't feel like spending them implementing a technically inferior specification to the one I already have.  I would rather spend them developing diaspora* support (or zot support, or dfrn support..) because that protocol offers us something we do not already have and there is a desire for (proper privacy controls)
   3. lnxw48a1 (lnxw48a1@nu.federati.net)'s status on Sunday, 28-Jan-2018 12:04:05 EST lnxw48a1

      in reply to
      @infernalturtle @maiyannah I read some of the very early drafts, when it was not much more than a clone of the pump\.io protocol. At that time, it was seriously deficient. I have not read any recent drafts, nor the final standard, but hopefully, it is much improved.
      1. Annah (maiyannah@community.highlandarrow.com)'s status on Sunday, 28-Jan-2018 12:24:20 EST Annah

         in reply to
         @lnxw48a1 @infernalturtle The material changes was the removal of the source field in the notices sent out (why would you need to know that?) and a lot of security flaws.  They at least acknowledge the flaws in the specification but that's not really a great change.