#social 2019-09-23
2019-09-23 UTC
xmpp-social and BitBot joined the channel
# 
Gargron Hey, can we have some property like manuallyApprovesFollowers but which communicates that direct messages will be ignored? something like acceptsDirectMessages: URI_of_followers_collection et
# Gargron *etc
# cjslep[m] Are follower collections always public? So clients can determine whether to enable DMs? I thought not necessarily...
# 
jaywink[m] I believe whether the followers collection is public or not is a platform specific thing
# Gargron collection doesn't have to be public
# Gargron it's just a URI
# Gargron like public collection URI could be another value
# jaywink[m] a bit confused why `acceptsDirectMessages` would refer to a followers collection? 🤔
# Gargron well yeah to be fair that's useless, it should be the "following" collection. i.e. only accept DMs from people this person follows
# jaywink[m] ah right
# rigelk[m] jaywink: to advertise what accounts can send direct messages to the actor? Then maybe `acceptsDirectMessagesFrom` would be a better fit.
# jaywink[m] direct messages are a bit of a platform specific thing too since it doesn't natively have such a thing except if it's "not public", I think? Not saying such a property would not be needed, just thinking out aloud :)
# jaywink[m] what about a more generic `acceptMessagesFrom` instead of referencing a visibility?
# Gargron well, in mastodon there are separate settings like "hide mentions from people you don't follow" and "hide DMs from people you don't follow" and it makes sense because DMs from strangers are a lot creepier
# Gargron you're right that AP doesn't have a specific concept of "DM", or rather, it is the default (when no collection is addressed)
# cjslep[m] Is the long term solution OCAP? If so, I guess it's too far in the future?
# cjslep[m] Is the feature being built, one to restrict clients from sending DMs to another federated account? So trying to get a system in place similar to how Mastodon federated Blocks so the client knows not to interact?
# cjslep[m] If all the above is "yes"... I'd prefer adopting an ACL or Policy ontology that can be: 1, leveraged in other contexts (not just DMs) and 2, be rich enough to let users set fine grained permissions as desired and 3, descriptive enough for clients to be able to self, apply policies on their end and enable/disable UI elements accordingly.
# cjslep[m] This is the direction I'm going with apcore, as a heads up.
# cjslep[m] That way, we can create all our custom app "dmPolicy" and "federationPolicy" and "imagePolicy" or what have you to our hears content, and don't need to revisit the wheel for every new permission related feature.
# cjslep[m] Heart's content*
KjetilK joined the channel