Piero Bosio Social Web Site Personale

@julian yeah, heavy on people who look more at the 'growth hackability' coefficient and profitability, than moral compass or the amount of soul you have to sell.

But there are roughly 2 crowds on HN. A sizable group is comparable to value-aligned folks you find here on the fediverse. They are the ones making critical notes, and ensure many of the good articles pop up on the front page.

And as a humane tech activist it is relatively easy to 'bump' the positive messages that blissful unaware devs need to see, to raise awareness on things. Esp. if you are in Europe it is relatively easy to get things to the front page that highlight the big problems of our modern tech.

@boebels Exactly! 😃

It is good that there are calls to be/remain wary.

https://kevinak.se/blog/be-wary-of-bluesky

https://news.ycombinator.com/item?id=47095597

Detecting issues early, and future problems can be anticipated and prepared for. And it allows people to make informed technology decisions and weigh the pros and cons, the risks.

There are currently all kinds of typical tech ideology and protocol wars being waged, yet the answer to "Should I use this technology?" always starts with "It depends.."

I am in the #ActivityPub camp for many of the reasons mentioned in the article. At the same time I am a multi-protocol #SocialWeb proponent. Use whatever works best to satisfy needs and forms a solution.

The article also rightfully states that you are not safe from re-centralization risks and corporate capture with any protocol. Esp. not based on the protocol alone.

Did we ever honestly investigate risks to our #fediverse? What if we get big uptake, adoption, billions of fedizens? What shape will that take. Will it bring us "true social"?

@reiver

Btw, I am sorry as I should've added "tangential" to the above, but was out of chars. I borrowed your post to continue my argument made elsewhere.

Adding an analogy that popped up as a showerthought just now, to clarify further what I refer to..

In a different context someone who creates a Webshop webapp might ask:

> When is something a "Product" or "Invoice" in HTTP / HTML?

It is not fully equivalent, but demonstrative of how the concepts clash, mixing solution space with protocol vocabulary in language use.

Yet this is what happens continuously in all fediverse developer talk, sowing endless confusion, but also leads to complete different, incompatible views and expectations on what fediverse is, and where it is headed.

We have a laissez-faire fediverse. Handy, as you can just hack things in. But also directionless and random.

@thisismissem

@evan

So the area where my plans go I call "Residential social networking", geo-fenced but inter-connected social networking circles that cover a city, town, or rural area, and which enable their residents to not only create content on the network, but the dynamic apps and services based on local needs that exist in the area. The intent of a residential social network is to engage people *offline* and in activities that support the local economy. Or rather strengthens the Circles of Sustainability in SX terminology:

https://coding.social/blog/reimagine-social/#circles-of-sustainability

And all this should be a relatively low-code affair, directly accessible already for a first-time dev. This requires having a mature open standards based healthy technology foundation and thriving ecosystem.

I am a developer, though with rusty coding skills these days, and I might have started a fedi app design in 2018 or so. But this would not have led to the desired outcome, just throw one more app-centric software in the mix.

@evan @cwebber @steve

Thank you, that is nice to hear. I am however not an expert, am but a humble generalist and a person who'd love to be in that Solution developer stakeholder role. Who however does not see the fediverse trend in a direction where I'd adopt the technology for what I have in mind. Drifting away from "the promise" that I read in the #ActivityPub specs in 2017, and which at the time made me decide to lend a helping hand here and there as #SocialHub facilitator and tech advocate.

@evan @cwebber @steve

Not needed. I hope to be able to add some feedback to the AP API repo.

@evan @cwebber @steve

So why don't you use the word REST? I never encountered "read-write API". It is an informal term.

But that is not the point. You can have a REST API, fine. But that says nothing in itself. What does it expose? You might say "Duh.. ActivityPub!" but that is not very informative either. There is the notion of message exchange, and of an addressing mechanism, indicating higher level abstractions that conform to well-known architecture patterns, and would allow us to have more productive communication, delve less in implementation details and confusions of protocol behavior with solution design functionality, for starters.

@evan @cwebber @steve

Which was exactly what I also indicated above, and which aligns to that diagram as well.

@evan

> it's ok if you haven't heard of a REST API.

Well, you be you. I consider this a 'typical Evan remark' by now, dripping with sarcasm. It is a weird fit for someone who want to lead the #SocialCG efforts, I'd say.

Ah well. What I am talking about is architecture and design, and all the things that allow people to easily form a clear mental picture on how things fit together, wrap their head around the fediverse.

A HTTP interface is a very low-level thing, and clearly but one of the many moving parts that play a role in #ActivityPub based solution development.

Never defining this well, and having the documentation be scattered all across the fediverse in 1,001 random locations doesn't help. Meanwhile the dev talk that is going on for years remains very inefficient due to endless Babylonian speech confusion.

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

@cwebber @steve

@evan @steve

Another issue: Unclear protocol layers.

> I am not a fan of the idea that #ActivityPub is a message-passing system; it's a read-write API.

I'm not sure what a "read-write API" is, really. It 's a fuzzy term, whereas message based systems have well-defined architecture patterns and a body of IT knowledge and practice to apply them in robust communication systems. A 'Message API' has a generic, consistent interface.

The overarching goal of AS/AP should be empowerment of the Solution developer so they can directly focus on building use cases for their application or business domain. They should not have to think about any of the intrinsics of the protocol, like particular GETs and POSTs used to model protocol capabilities in the HTTP transport layer.

Solution design then involves:

0. Model the domain
1. Data modeling, msg formats + validation
2. Define actor msg exchange patterns
3. Document design
--
4. Improve these steps. Add native protocol + tool support over time.

@eyeinthesky

I am a former facilitator of SocialHub and part of the FEP team.

The whole idea of the FEP process is that it is accessible to all fedizens, and anyone can take the initiative and write, submit, and guide their own FEP document towards a FINAL status.

It is recommended practice to introduce a new FEP to the SocialHub developer forum for discussion, which the FEP forum category federates out. The forum thus also serves as an archive of past discussions around ActivityPub / fediverse evolution.

However, it is not *required* to discuss on SocialHub should you not want to do so for some reason. I'd say it has the disadvantage that it fragments discussion and it becomes harder to parse the 'body' of FEP's created over time. People would have to use the tracking issue accompanying a FEP to figure out where to discuss things.

But the freedom to choose is the important part. It helps lower the barrier to write FEP's.

@evan @steve

It is both, like in that diagram draft.. or at least could be considered such (the notes apply to Protosocial musings).

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

@steve @mariusor @evan

He he, language is hard. A case of terminology overload and clashing terms. Domain driven design has the clearly defined bounded context here which is the scope within which terms are valid. Forming a consistency boundary. These context lines are blurred in fediverse talk. 😅

@evan @steve

Rather than sharedInbox I was more thinking that by implementing the HTTP API and msg exchanges in a well-prescribed manner, these would effectively model an event bus conceptually. After which you can talk about it as a higher abstraction that exists, and not get lost in the reeds of the impl details anymore.

@evan @steve

Btw, wrt fediverse we really live in a multiverse by all the different perspectives people have towards what the network should or should not provide. All having different physics.

Where ActivityPub is gravity, and fediverse is entropy and chaos, and universes have become inaccessible over time, past stations.

@evan @steve

Well, but a part of the specs can certainly be considered a message bus with channels conceptually.

Channel is the name that AsyncAPI uses, which maps to domain aggregates and actor streams.

But considering things purely event-based is stretching it, and may be better to discern between commands and events.

@evan @steve

The way I see it, this has the wrong stakeholder name of "ActivityPub API client developer" i.e. spec implementer, and a Home Feed is something I may want as a "Solution developer" stakeholder. In other words that library or SDK that offers me the Social API should allow me to model that.

The user story was also brought up by Mastodon, a Microblogging solution built on top of AP (ideally).

@evan @steve

> I think it's fair to call the outbox the actor's 'feed'?

The actor's event bus in a pure event based approach. 😃

Does that break AP? Current fediverse?
Can AP be considered an event-driven architecture of sorts (or restrained as such in a solution design)?

I really like the Motivating use cases section of the AS specs, and the primer that sits on the W3C wiki to that. Those might be further formalized so they are applied consistently.

@mariusor @steve @evan

> And when I say "client", I mean a "consumer of ActivityPub", which as you say, many times is also a web server.

Indeed. Another term that I see people use in different meaning, also when talking about C2S.

In one meaning the user device is referred to, that you might need to hole-punch with to have a full AP server, or which depends on a server relay.

And the other meaning as role. As in client/server roles, pure conceptual, and which might swap too.