- From: Erwin Ernst Steinhammer <eest9@posteo.eu>
- Date: Sun, 30 Apr 2023 00:40:31 +0000
- To: public-swicg@w3.org
- Message-ID: <f82acc77-6094-5c49-db6e-8017d9690987@posteo.eu>
Dear Bob, it's interesting. My perception differs greatly from yours. While the first generation of ActivityPub Services practicly (re)implemented things already available in older federated ecosystems or on gated platforms, the current generation is onto implementing small but significant new innovative variations. One of these examples is Mobilizon, which isn't just a version of Facebook Events or meetup.com, it surpasses these systems by providing functions to make it easier to organize and plan events! Also, that we see how a multitude of sites implement ActivityPub as a form of social Feed when they dropped RSS long ago. Projects like Mobilizon, bookwyrm, etc. show that there is true innovative power in this system. And with the acquiring of new users it will get easier to start and test innovative ideas. Because you always have a network of users you can rely on. While you have to build a new user base when you try to build a novel idea as a gated platform. But as you pointed out, another federated system always could surpass the Fediverse. So what are the missing features? What are the prominent showstoppers? Which are problems that can be solved at the protocol, and which are questions of implementation? yours eest9 Am 30.04.23 um 00:41 schrieb Bob Wyman: > 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. > > 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/ >
Received on Sunday, 30 April 2023 00:41:50 UTC