THIS IS SO IMPORTANT. Thank you for posting.
I was chatting with @rhiaro recently…
I think we can share product and design planning across protocol-specific ecosystems
eg the same “reference design” for a given use case can be an input to [many ecosystems (e.g. socialhub, web3)]
What is the “north star” of “What should it look like to use the fediverse?” Regardless of whether ActivityPub is the implementation detail 100% of the time.
IMO it’s obvious that the fediverse must be multi-protocol and (in blockchain jargon) “multi-chain”. ActivityPub is only a tool for certain use cases, but the goal isn’t ActivityPub its serving the humans trying to communicate.
I think one way of organizing community around this is to go back to SocialWG use cases document and “see how we’ve done [so far]”.
Crowdsource feedback on each one, celebrate the “done” ones (and solicit champions to evangelize/document).
Reprioritize the “not done” ones and have their be ONE SINGLE TOP PRIORITY that people are encouraged to work on if they just want to do a high value small thing (#good-first-issue)
Organizations or individuals with funds can the place bounties on the use cases…
The idea is to cooperate on ‘reference designs’ for important use cases for social computing. And prioritize that as its own end over code. It’s making what needs to be coded easier to code when the time is right.
The idea is to avoid doing anything about any particular protocol, and to cooperatively design our social computation.
I’m quite optimistic that ActivityStreams and ActivityPub can represent all kinds of things, not just a ‘general purpose’ social network or twitdeck-style UI.
I’d like to work more on brainstorming which specific experiences we should prioritize actually proving out that are valuable, and subsequently people can propose candidate solutions with specific UML or protocols.
These kinds of design artifacts (e.g. ‘use cases’ or ‘jobs to be done’ or ‘frequently asked question’) may be the most valuable encoding of information out there. If we can articulate those, then they will be useful to all kinds of stakeholders, inside socialhub, EC, and beyond. Those design artifacts could inspired hundreds or millions of different ‘homegrown’ solutions that make sense in their natural/local context (or jurisdiction).
Inspiration:
Backstory:
You know, I first heard about ‘activity streams’ in 2010 from a handful of Google, Microsoft, and Facebook employees…
In 2010, things weren’t quite like they were now. Everyday people consumed ‘news’ in a very different way than they do now…
Upstart news products had to bootstrap their Activity dataset somehow so the Activity Streams weren’t empty. It made sense to cooperate and interoperate to gain early traction… (this was also at a time when gchat and fb chat used XMPP…).
Early versions of Facebooks Open API used ActivityStreams XML. Same with MySpace and Microsoft products. Google Buzz tech may have been quite similar to Open Social tech. Google indexer understands a lot about JSON-LD.
Over the last 10+ years, many of these companies have made some quite successful products that everyday people like to use in part because the product marketing does not focus on protocols or theoretical use cases that don’t work in practice. Instead, a lot of those people worked on products that if not decentralized (nee ‘distributed’ e.g. ‘DiSo’), were often useful to people and helped them perform their daily activities in the easiest way available. Let’s learn from that.
These same early ideators about activity streams syntax also talked about various semantics. For example, one presentation around 2011 is where I first learned about “Activity Theory” (SSAT or CHAT).
@aschrijver What you describe in this thread reminds me of “Activity-Centered Design”. I think there’s something awesome about the genealogy of ideas looping back on itself as it does in this strange loop.
Activity-centered design ( ACD ) is an extension of the Human-centered design paradigm in interaction design.[1] ACD features heavier emphasis on the activities that a user would perform with a given piece of technology. ACD has its theoretical underpinnings in activity theory,[2] from which activities can be defined as actions taken by a user to achieve a goal.[3]
When working with activity-centered design, the designers use research to get insights of the users. Observations and interviews are typical approaches to learn more about the users’ behavior. By mapping users’ activities and tasks, the designer may notice missing tasks for the activity to become more easy to perform, and thus design solutions to accomplish those tasks.