Re: Survey -- observations and ideas

ne 30. 4. 2023 v 0:42 odesílatel Bob Wyman <bob@wyman.us> napsal:

> Johannes,
> While the survey indicates that "On balance, people here believe there are
> things to be done," it is clear that the interest in innovations and
> exploring new opportunities is dramatically less strong in the
> ActivityPub/Mastodon community than it is in other communities. For
> instance, I've been monitoring the BlueSky and Nostr communities, as well
> as some others, and it is quite apparent that those other communities are
> much more aggressively and passionately pursuing new ideas for addressing
> real end-user problems and needs than is the ActivityPub community. Some
> might argue that this is simply because, as an older protocol, ActivityPub
> has already solved many of the challenges only now being addressed by
> others. However, it might also be observed that ActivityPub,
> particularly in partial adoption by Mastodon and its forks, has already
> accumulated such a high degree of implementation debt that ActivityPub's
> most influential supporters are, of necessity, now extremely conservative.
> Essentially, that there is complacency in one community, but not in the
> others.
>
> As I, and others, have pointed out, even the "millions" of people who use
> ActivityPub today are a mere drop in the bucket compared to the billions
> who regularly use closed, proprietary systems. Given that, I don't consider
> the user counts of existing ActivityPub systems to indicate that they have
> sufficient momentum to even eventually displace those proprietary systems.
> Given that the non-proprietary, open systems still serve such a tiny number
> of users, it seems to me that none of them can claim any particular
> long-term advantage over the others. Mastodon may have gained millions of
> users since November, but we're just as likely to see BlueSky or Nostr add
> "millions" of users over the next year and close the gap, or grow beyond
> the number now using ActivityPub. In such a dynamic and unsettled
> environment, I find it hard to understand how one could prioritize
> "non-breaking changes" over changes which make a system more or better able
> to serve its users' needs.. Personally, I would phrase the requirement more
> like "break nothing without good cause..."  Certainly, we should not be
> casual about encouraging breaking changes, but If good cause exists, then
> breakage is inevitable -- either by changes to the protocol or through
> displacement by other systems. (Irrelevance and obsolescence are the
> ultimate "breakage.")
>
> I am beginning to believe that the real challenge for this particular
> SocialWeb community isn't so much a technical one of addressing issues with
> or limitations of the current specs, but rather one of figuring out how to
> engender an increased sense of the value of addressing issues and
> encouraging innovation. I've seen a great many protocols and systems come
> and go during the ~50 years that I've been involved in software
> development. Although not always the case, I can assure you that the
> general pattern is that once a community believes that its specification
> task is "done," one can be sure that it will, in time, become an irrelevant
> legacy.
>

It is the case that it is *REALLY* hard to get developers to build on your
project.  I spent years doing this in Solid.  The developer experience
counts for a LOT.  If I could on board 2 devs in a year to solid that would
be a great achievement and a full time 24/7+weekends task.  Because Solid
is complex and a steep learning curve.  Nostr OTOH is a 2 page spec, it
works, is bug free, interoperable and consistent with itself.  Developers
can learn it in an hour, and build a client or server in a weekend, and
many do.  Consequently 1000+ developers have been on boarded in the last 6
months, in person conference in costa rica had 400 attendees and the pace
of innovation is high.  People fix problems and solve things overnight,
standards emerge spontaneously.  They are not always the best, but they
work.  AP is somewhere in the middle, a bigger userbase, but the devX is
hard, the spec has many bugs, and interop is hard.  Bluesky by all accounts
spent their millions wisely on an excellent microblogging app, but it's
proprietary and the app is closed source, the mind set is proprietary.
Interop is an after thought and the protocol is not well thought out (e.g.
their URI scheme is called "placeholder").

In terms of fediverse the devX is still a heavy lift, and the bugs and
inconsistencies are limiting.  But it's an exciting time.  A year from now
so much can change.  It will be interesting to look back and see the
delta.  Personally, I hope that all the systems can interop and that we can
have a diverse set of developers working together with a great devX.


>
> bob wyman
>
> On Sat, Apr 29, 2023 at 4:10 PM Johannes Ernst <johannes.ernst@gmail.com>
> wrote:
>
>> Some observations from the survey results:
>>
>> * On balance, people here believe there are things to be done. (I wasn’t
>> so sure before this survey!)
>> * On balance, people here want to do things.
>> * Different people want to do different things — no surprise here.
>> * Not too many people are willing and in the position to do “significant”
>> work. But many are willing and able to do some work.
>> * Some dependencies were identified — e.g. “search” would benefit from
>> “terms for content"
>> * Some of the potential work areas are controversial — as evidenced by
>> votes both for doing it and not doing it at all. But many are not
>> controversial.
>> * (I also think that some votes and comments are based on
>> misunderstandings, but that’s okay)
>>
>> So I think in the short term, we should pick one or two work areas from
>> the list, where
>>
>> * several people said they could and want to spend some, or a significant
>> amount of work on
>> * nobody, or few people, objected to the work
>> * the work was rated as important/urgent by enough people.
>>
>> Clearly, non-breaking fixes and clarifications should be done — perhaps
>> this can be done with the existing errata process, and Evan is already on
>> it.
>>
>> For new work, to me,
>> “improved security and privacy”
>> stands out as non-controversial, enough people feel urgency and there are
>> some resources. Of course, we would have to determine what exactly
>> “improved security and privacy” should actually mean here :-)
>>
>> Also, lots of people want to find out why not more developers have
>> implemented the client-to-server spec.
>>
>> Perhaps we could create some informal working groups where the people
>> participate who want to work on a particular subject? (And also make sure
>> that they don’t work in a vacuum and have participation from people who
>> would actually implement this.)
>>
>> Your thoughts?
>>
>> Cheers,
>>
>>
>>
>>
>> Johannes.
>>
>>
>>
>> Johannes Ernst
>> Blog: https://reb00ted.org/
>> FediForum: https://fediforum.org/
>> Dazzle: https://dazzle.town/
>>
>>