Piero Bosio Social Web Site Personale

@trwnh @evan @julian

Yes, for the ideation on Protosocial as an #ActivityPub compliant extension (going back to the roots with blank slate W3C specs) I imagined mapping the AS primitives to consistent protocol capabilities and thereby define a set of normative architecture patterns, like "this is how we do CRUD, this is Publish/Subscribe, this is an Event stream and this a Collection", etc.

Then Protosocial library and SDK implementers would need to deal with #ActivityStreams at a low-level plumbing impl detail, while solution developers would have a higher-level API to invoke these patterns. And other than that would not need to touch #ActivityStreams which is now entirely reserved to making AP work on the wire.

A combination of linked data practices and schema-based design would be used for both open-world and closed-world extension modeling. But here too the solution developer should be shield from the nitty gritty internal mechanics.

@julian @evan

Btw, some time ago in a matrix discussion I sketched how I'd like to conceptually 'see' the social network. Not Mastodon-compliant per se (though it might be via a Profile or Bridge) but back to "promised land". Where the protocol is expressed in familiar architecture patterns and borrows concepts from message queuing, actor model, event-driven architecture, etc.

Then as a "Solution designer" I am a stakeholder that wants to be completely shielded from all that jazz. That should all be encapsulated by the protocol libraries and SDK's that are offered in language variants across the ecosystem. #ActivityPub et al is a black box. I can directly start modeling what should be exchanged on the bus, and I can apply domain driven design here. And if I have a semantic web part of my app I'd use linked data modeling best-practices.

I would have power tools like #EventCatalog and methods like #EventModeling.

https://www.eventcatalog.dev/features/visualization

https://eventmodeling.org/

@julian @evan

No need to, I didn't call you out :)

I think the fediverse-we-have has become a very different one than the fediverse-promised based on the initial specs when there weren't implementations and an installed base making numerous design decisions in a very ad-hoc pragmatic fashion. Which is in itself fine, and a very good approach to get an ecosystem off the ground. But having the app-centric, app-first evolution be the primary evolution process, brought us to a different space than the ubiquitous, heterogeneous social networking environment we might all be working in, focused on exciting solution designs and less in all the plumbing and impl details.

No one is really to blame I guess. This is where laissez-faire in grassroots environments leads us, following the social dynamics that exist.

We can do better, but it is very hard in our individualist, FOSS-project-oriented herding of cats chaotic environment. The challenges are social in nature..

https://discuss.coding.social/t/major-challenges-for-the-fediverse/67

@evan @julian

#ActivityPub builds on top of #ActivityStreams in the sense that it adopted a number of its 'social primitives' defined in its vocabulary, and Collection being among those. These particular uses become 'protocol space', but other than that AS from the perspective of AP solution development is purely a set of social primitives, granular building blocks that one *may* use in a solution. AS is a utility library of sorts then. Or is that a wrong perception?

A 'feed' is something that lives in solution space, and I would only choose Collection to model it, if it offers a perfect fit in functionality. And aboveall.. does not assign some new app-specific use along the way.

I tooted today that I feel the biggest folly of the fedi is that everyone tries to cram their domain into the AS namespace. The AS primitives should not be Swiss army knives and have only singular well-defined meaning and purpose, yet they have become that along the way.

https://social.coop/@smallcircles/116096886732404993

@evan @julian @deadsuperhero

Except when they are called other names instead ;p

A timeline is a different thing than a collection imho. And an AS collection has some very particular functionality, which if I model a timeline in my app may not supported (e.g. reverse ordering).

Collection / 'timeline' is one of those words where sometimes they indicate an app domain, and sometimes a core protocol mechanism. Same is true with 'follow' which is sometimes a user action, sometimes indicates low-level publish/subscribe.

For core capabilities that must be part of the specs, in 'protocol space' it may be better to use terminology that is more common in messaging architectures and all the various architecture patterns that are involved. Perhaps idk we deal with a time-ordered event log or something like that.

@julian @deadsuperhero @evan

Can't help but wonder about terminology use and abstractions they indicate. Nowhere in the specs is there mention of 'timeline' and neither of 'feed' (except as example use in AS).

I feel we started with powerful specs to be able to model *any* social networking use case. But where the specs had blanks gradually the impls filled these in with leaky abstractions such that fedi is now hammered into a very narrow social media microblogging domain.

If an app needs "Timeline" and "Feed" concepts, then it should model them. Given the actor-based nature of AP they might be actors, or whatever is best. These concept are about solution development, i.e. what is built on top of the protocol, and not indicative of core protocol capabilities.

There's so much confusion on "where does the protocol end vs. where does my app design start".

SDK's should offer "Addressable actors exchanging msgs with object payload", and hide all impl details for the solution developer.

@thisismissem @deadsuperhero

I was looking at #ForgeFed which is a very sizable #ActivityPub extension (constituting the "Code forge" app domain in app-centric view, but arguably "Software development" top-level business domain in a service-oriented fedi).

The way that things are modeled here adheres more to the actor model where there's a Factory actor, which in turn creates resource actors that expose various sub-domains. For instance for the management of Issues and PR's there's a TicketTracker actor to obtain via a Factory actor on a forge instance. Though I'm not sure whether I'd modeled that in similar fashion, it is a fascinating direction where we focus much more on good protocol extension design.

All in all AS/AP offers a very granular foundation that allows for very interesting architectures, if only we dare explore them and do not dogmatically stick to some engrained notion how "social media" ought to be. I see #SocialMedia as but a small subset of #SocialNetworking.

@deadsuperhero

It does not need to be that way. I am quite happy after all (after being initially frustrated) by how #ATProto has disrupted things, and opened the eyes of devs in the #ActivityPub ecosystem that we must act or lose out (stay niche, which may be fine too) to the Atmoshpere and how it enables devs to focus on service and product delivery instead of low-level wire plumbing and continuous breakages.

ATProto also shows the way that we can now follow on the #fediverse to catch up again: cocreate a similar robust basis for people to build on. #Bluesky had the advantage of a greenfield start and dedicated team unburdened by past decisions. And they build this whole Lexicon system and ways to introspect functionality.

We can do that too, solve the #LinkedData conundrum, and create an extensibility mechanism that allows devs to focus on service modeling. The more introspection this mechanism allows for, the less design-by-consensus is required, easing expansion to new domains.

@deadsuperhero

Right now extensibility of #ActivityPub shapes up as custom app-by-app app-centric development where individual devs just pragmatically throw new stuff on the wire, and when their app gains any popularity or other apps to integrate in a similarish application, things are bolted onto that in random ways. That whole story really constitutes a Big Ball of Mud anti-pattern that only introduces protocol decay, tech debt, and whack-a-mole programming, that is very hard to get rid of once there exists an installed base.

The reason that we do things that way is very understandable. It works in a grassroots environment where indivualist devs find it very hard and not valuable to collaborate at scale in what amounts to a kind of design-by-consensus process. But it comes at a high cost, where interoperability is basically out the door and any app has to be shaped as a pretzel and adopt all the quirks introduced by predecessors in a particular app domain to fit itself on the wire.

@deadsuperhero

Yes. Mastodon has always given their own product decisions precedence over healthy evolution of the ecosystem as a whole. And despite many people being very frustrated about that, I think this is perfectly valid decision. After all choosing to implement an open standard should not come with the obligation to maintain/evolve that standard. It is only smart to do so, and Mastodon did this with an eye on their own product development.

Imho it is really the broader dev ecosystem that is at fault in letting the fedi be taken hostage by past Mastodon decisions, making them the post-facto #interoperability leader. As for Mastodon API I'd argue that its users are not on the fediverse. They are on Mastodon.

Identity management may be killer feature, but only when first a sound #ActivityPub foundation is in place. AS/AP isn't as-yet robust enough to be the future of social networking. I'd say the extensibility mechanism is killer feature, and having SDK's and devtools for that.

Read about #Encyclia by @jfietkau and plans to bring more #OpenScience to our #fediverse

https://discuss.coding.social/t/my-current-goals-for-activitypub-and-academic-data/750

There are multiple other #ActivityPub projects that share interests to connect more tightly the academic world to the #SocialWeb.

Backed by #NGI0 @nlnet funding there is the very promising @bonfire and #Plaudit in earlier rounds (#WebMentions, not fedi).

We should align on #OpenStandards

https://encyclia.pub
https://bonfirenetworks.org
https://plaudit.pub

#SX #Socialcoding

#OpenScience and the #fediverse .. let's get that ball rolling 💪

@jfietkau @jonny and @bonfire opened a brainstorm and evaluation on how we can provide better support for the academic world and #science in general to the #ActivityPub-based fediverse.

Various different iniitiatives are underway, and there's great opportunity to bundle forces and align these efforts where possible. Set standards.

Interested? Join the discussion:

https://discuss.coding.social/t/my-current-goals-for-activitypub-and-academic-data/750

#LinkedData #SemanticWeb #JSONLD #RDF

@daniel @fiskfan1999 @berlinfediday

I am not sure if I misunderstand, but you can paste the URL of your #Peertube vid in the search bar of your own instance, find it, and then boost it. Everyone then gets the actual peertube vid in their timeline and Likes and Comments go to the video.