🫧 socialcoding..Do NOT create out-of-bound custom and app-centric mechanisms that define new and expected behavior on protocol level.
https://codeberg.org/fediverse/fediverse-ideas/issues/33
#SX #SocialCoding #SocialWeb #ActivityPub #ProtocolDecay #Botiquette
cc @evan relating to earlier #TagsPub discussion we had on the matter.
This bot is already combining logic, has multiple 'profle logic' tags. Dunno if "NoBots" is also already common protocol-decaying practice.
Maybe a solution might be that an #ActivityPub bot actor - OT: which I'd personally perhaps had chosen to be Application, not Service actors - would have a botFlags property. Simple to implement, and #FEP that.
More involved but also much more versatile might be a "Botiquette" as:Profile, or even a bots:Botiquette type, and a namespace to register them at, and where others may find what they mean and how they operate exactly.
Evan Prodromou@smallcircles thanks! Service is for servers, Application is for clients.
@smallcircles I think it might be possible to do something with the "extra profile fields", but we get so few by default!
@evan 2x protocol decay in a row? 🤔
Is there any formalized approach on choosing actor type, or did you express your personal app-centric preference? Is there anything not app-centric to having a max. amount of app-centric 'profile fields'? Genuine questions. Am I holding it wrong when I say 'app-centric'?
@smallcircles you use an idiosyncratic jargon sometimes and that makes it hard to talk to you.
Evolution of a protocol is not "decay". Nor is the Postel principle. Learning and adapting protocols and data types to new situations or creating extensions is success, not failure.
@smallcircles for choosing object types for software, I think the difference between a client and a server can be tricky, but in the case of tags.pub, everything is implemented on the server, so I think Service is a good choice. Why do you think Application?
@smallcircles when you say things are my "personal" preference, you make it sound like I am just some guy off the street. I'm not. I wrote StatusNet and pump.io. I developed OStatus, and cowrote AS2 and AP. I wrote the book about ActivityPub. My personal preferences were built into the standard a long time ago.
@smallcircles I think the question you are asking is how we let people express their preferences for interacting with different types of automated actors. I think the NoBots solution is fine; it reminds me of robots.txt. "indexable" and "discoverable" are also fine.
@smallcircles Long term, I think it would be great to have a structured way to add properties and collections to actors that don't depend on the server software.
So, I could say, if you don't want tags.pub to boost your content, set the `https://tags.pub/ns/noTagsPub` property on your actor object to true. Or have a collection of allowed tags, or denied tags, or object types to boost, or object types not to boost.
@smallcircles I'm not sure what you mean by app-centric. I think you mean Mastodon-centric, that is, how do we work around the Mastodon software and the Mastodon team? I agree that it is a frustrating part of working on the Fediverse.
@smallcircles Anyway, yes, the way the extra fields work and their limited number is a product decision by Mastodon.
What is app-centric. Mastodon is one example, but all increments to 'what constitutes fedi' come from app development, where post-facto interoperability takes place.
So Peertube at the time they extended AP were the first to do so in a Video domain, and could freely define AP types and props. Choose them for best-fit with their app.
The next Video app builder then has a choice. "Do I follow that? But it is so peertube specific. Do I want to include their namespace in all my messages and then add my own app-specific namespace for the new props I introduce that maps to my app's features best?"
This is a Grassroots standardization process thingy where ideally..
- Peertube being first is free to extend.
- When the next app dev comes in that business / application domain we weigh the impact, perhaps conclude no coordination is needed yet.
- When more apps come, there's need to formulate a standardize approach. Consolidate protocol decay, and rebalance specs with wire reality.
What I thought to do the other day we had the discussion, but didn't have time for, was create the hypotethical future Mastodon profile of my account, where some technical construct of tags took all the available profile bio characters leaving just enough to say "Hi, I am Arnold (out or chars)" followed by a combinatorial mismash of app-specific profile-logic I require to have to operate my account on the fedi to work well.
It is protocol decay. AP let's you express that kinda logic, and it was made to convey these things.
It is both protocol decay as well as "misconception" in the way Rich Hickey meant in his Hammock Driven Development talk.
The longer such practices are allowed to exist, the more inertia and reluctance to there is to come to better practices, and the question about evolution is again Im Frage.
"Look we all have bio profile processors in our apps, and now you are telling us to drop that, just to make it look more like activitypub? We can see that it may be an improvement, but this is a past station now."
There are more aspects to evolution. When I use the word, it is from the full scope and against the principles of SX methodology I am working on, which holistically considers the entirety of the ecosystem as a whole.
The fediverse ecosystem evolved to have most day to day conversation on microblog channels.
But if those are ephemeral and fleety, fragmented, where before the discussions on more cohesive commucation hubs that kept an archive of what was said in one place, from that perspective and measured against power that is now lost, one may conclude devolution to place in hindsight.
To me it is very sad this shift to fragmented microblog being the source of truth to discuss de-facto standards and upcoming potential post-facto interoperabiliy tech debt, in a communication medium where only you and I may ever read our discussion, and it is gone in timeline history the next day.
@smallcircles Sorry about that! Where would you prefer to talk about it? SocialHub?
@evan it was more a general remark, as I am having these kinds of discussions all over the fedi place now, and always to people who miss context on what I sent just previously in another branch or toot thread. I sighed about the general fragmentation of things, where more cohesion is not just a boon, but perhaps a requirement for healthy standard evolution.
In my brainstorm encouragement about Grassroots standardization processes, and my line of thinking this could be tackled property, and on fedi space, integrated in the social fabric.
Other than that a forum or issue/discussion tracker might work for the time being.
bhaugen@smallcircles @evan
this seems like an important discussion. Should be saved in some standard place.
Where should that be? I think the participants in this thread would be candidates to decide (or create) the place.
this seems like an important discussion. Should be saved in some standard place.
Where should that be? I think the participants in this thread would be candidates to decide (or create) the place.
Well, from my perspective, https://discuss.coding.social is the right place. It is intended to be a note-taking tool and archive of incremental value for the commons, more than it is a regular discussion forum. In terms of the SX Prosperity guilds formula that I am concept developing it is called a Prosperity vault. A storage point for commons based knowledge in this case.
One of SX main objectives is to bridge the big gap that tech leaves to reach people and society in their actual needs. Add the social layers to the tech stack, foster sociosphere on top of technosphere. Imagine a peopleverse and make progress to realize that dream.
It is not meant that way at all. I mean "any developer's personal choice at time of impl" because the standard allows such versatility. Since in this case you posed it to me its "you as a dev's personal choice". There are 3 options:
1. It is not standardized, everyone is free to choose.
2. There's an informal convention, turning de facto standard.
3. It is formalized, part of the standard.
When saying "protocol decay" I always mean as the IETF doc on it defines it: https://www.rfc-editor.org/rfc/rfc9413.html#name-protocol-decay
On "evolution". Evolution to where? What are the common goals, the shared vision? When is something evolution vs. devolution if people are hemmed into a de facto standard full of app-specific choices made in the past?
"I can't have more profile fields". Why? Does Linked Data restrict you, or does some app not handle more than N fields? The latter is protocol decay.
I've been tooting about Emergence. Many emergent systems in Nature have no interesting outcome. What fedi is emerging?
RFC 9413: Maintaining Robust Protocols
The main goal of the networking standards process is to enable the long-term interoperability of protocols. This document describes active protocol maintenance, a means to accomplish that goal. By evolving specifications and implementations, it is possible to reduce ambiguity over time and create a healthy ecosystem. The robustness principle, often phrased as "be conservative in what you send, and liberal in what you accept", has long guided the design and implementation of Internet protocols. However, it has been interpreted in a variety of ways. While some interpretations help ensure the health of the Internet, others can negatively affect interoperability over time. When a protocol is actively maintained, protocol designers and implementers can avoid these pitfalls.
If after a bunch of years the AP dev community came all together in a big event and reflected on the past, suppose they might conclude:
"We have evolved into a decentralized copy of existing big tech social media platforms."
You can say that it is evolution, and you'd be right too. But is it the best evolution we could have had? Which branch of the Tree of Fedi Life did we grow?
If now that branch can only form microblog-like sub-branches, is it evolution? Evolution is in the eye of the beholder.
I am inclined even say that ActivityPub in its original raw potential constitute magic seeds for trees that over time will form a large forest, whereas fedi has branched from the single tree, and you can choose to be a sub-branch.
Both can technically be said to constitute progress. But one has more power and promise for rich tapestry social web.