#AntiPatterned™
-
Do NOT create out-of-bound custom and app-centric mechanisms that define new and expected behavior on protocol level.
#SX #SocialCoding #SocialWeb #ActivityPub #ProtocolDecay #Botiquette
-
Do NOT create out-of-bound custom and app-centric mechanisms that define new and expected behavior on protocol level.
#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.
-
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.
@smallcircles thanks! Service is for servers, Application is for clients.
-
@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!
-
@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'?
-
@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.
-
R relay@relay.mycrowd.ca shared this topicSystem shared this topic
-
@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 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 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 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.
