🫧 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.