#AntiPatterned™

#AntiPatterned

Do NOT create out-of-bound custom and app-centric mechanisms that define new and expected behavior on protocol level.

#Botiquette

fediverse-ideas - Ideas for new applications and services on the Fediverse.

Codeberg.org (codeberg.org)

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

#NoBots #nobot #fedi22 #NoTagsPub #Botiquette

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