yup. there is use `audience` and `discoverable` instead of `to`/`cc` "magic semantics" to determine scope/privacy level · Issue #18212 · mastodon/mastodon · GitHub but currently mastodon does not support arbitrary audiences and it does not even check the audience property.
that’s because “delivery” is the only thing in the AP spec. “visibility”/“scope” is a concept made up by mastodon that only loosely maps onto delivery targets. in reality, when you put a message in sharedInbox, the server can do whatever it wants or thinks is appropriate. this is the basis on which “followers only” posts work – you address your followers collection and mastodon treats it as another “magic collection” similar to Public. the argument was that servers already know who is following who. christine webber later cited this as a huge mistake that broke the actor model, and what should have been done is to specify every single inbox you wanted to target in an http header or something, then post that to a “multibox” endpoint for the server to distribute to the indicated inboxes only.
I think by doing a technical exploration of this and reporting here. I kind of made this thread drift off-topic. I’m still interested in the answer, would the following:
- Posts only appear on a curated list of followers
- Posts are still public, e.g. a share by Alice results in all of Alice’s followers seeing the post
make the situation better? Of course, Alice might also only share with her curated “no VC dudettes” list.
yep, the is an avalanche of well-meaning poisonous people around, what are you thinking of doing to mediate this flow?
Hint I am not sure limiting post visibility is a useful ansear to this problem, not agenst it, just likely not useful to solve the issue 
i think arbitrary audiences is a useful thing to have, but it’s not really related to “public”. for that, i think we should maybe disambiguate and allow people to actually “publish” rather than simply “post”. after something is published, you can then dedicate it to the public domain, or otherwise you may reserve some rights and place restrictions like Creative Commons lets you do (BY, NC, SA, ND)
the key part of being “published” is that instead of only seeing what is delivered, you can actively browse for it at the source.
1 Like
The use of a Rights Expression Language (REL), such as ODRL, would allow you to specify the time period during which you permit your post to be stored, distributed, etc. The ODRL specification includes an example of a “distribute” permission with a time constraint that limits the duration of that permission’s validity. [See copied example text below]
Use of a REL would provide individuals a consistent and powerful means of expressing fine-grained control over how long their posts might be “stored,” “archived,” “distributed,” “replied-to,” or whatever. (We’d need to define an appropriate permissions vocabulary.) A specific instance might have local defaults, but the REL would allow those defaults to be overridden to reflect the needs or preferences of individual users.
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:6163",
"profile": "http://example.com/odrl:profile:10",
"permission": [{
"target": "http://example.com/document:1234",
"assigner": "http://example.com/org:616",
"action": "distribute",
"constraint": [{
"leftOperand": "dateTime",
"operator": "lt",
"rightOperand": { "@value": "2018-01-01", "@type": "xsd:date" }
}]
}]
}
I completely agree. This unfortunately only solves half the problem. As was nicely put earlier in this thread:
Let me continue my Mastodon bashing. I’m really on a roll with it. Mastodon sets Cache-Control headers of 3 minutes, whenever you request an object. This is too short to for example pre cache an announce activity. I don’t believe even chronic online people check their social media every 3 minutes. So it gets ignored.
On the same side of the coin, Mastodon doesn’t seem to respect cache-control headers when fetching stuff. See mastodon/jsonld_helper.rb at b46125224c26bc0144659b4319ea416b01289961 · mastodon/mastodon · GitHub.
I personally think that the technical site of this “posts with a time to live” is much easier than actually agreeing on what is reasonable and getting people to implement it. One can say that, it boils down to a trust model. If I want to use a REL effectively, I need to trust my counterparts to do the same.
As mentioned elsewhere, one solution to this type of problem is a “server to server”-protocol in addition to ActivityPub. In the language of politics, servers would negotiate treaties that allow more or less access to their actors data. One possible implementation of it would be
- Allied server gets all public content
- Neural server gets 1 in 3 public posts
- Enemy server gets 1 in 100 public posts
Names and suggested numbers not to be taken seriously. This would require a reformulation of the description of “as:Public” in the ActivityPub Specification.
1 Like
I find this a problematic term and an anthropologic issue that touches what group communication is like.
As an individuum there was rarely a time in history when one had such a huge possible fan-out. Few are prepared for the backlashes and just ignore they can happen anytime.
Maybe we need slower spread and shorter post-lifespans. Maybe at the originating site is sufficient. A copy without an ‘original’ isn’t too relevant as it is easy to make up.
What would be a good way to define the lifespan of a post for you?
left aside the impossibility to turn back time and undo things in reality, I’d prefer it threefold:
- delete the post at your own instance (the only place you have agency if at all),
- send an ‘undo’ activity to all you sent the create before,
- add an expiry date to the post to begin with (e.g. endTime).
1 Like
This is an example of a “native” path in coding, that is based on “trust” and clearly steps away from #mainstreaming ideas of #control that are often pushed into the #openweb space by #geekproblem thinking. If we code like this, it becomes easy to take the “problem” out of the “geek” #hashtag
We should not need to be continuously having this conversation BUT we are, it’s a #geekproblem
To recap @mro MRC
This is POWER we actually have, so CONTROL
This is power we don’t have, so TRUST
This is power you would like to have, but in the end, you can only TRUST the other instances.
This is the #fediverse of elephants stampeding in a storm of paper planes, #openweb native
1 Like
This is actually not an answer to the question, I was interested in. It answers
What would be a good way to implement the lifespan of a post for you?
I was thinking of stuff beyond the issue of implementations. For example, I am curious how one would want to specify lifetimes on a per post basis. So for example, one post about the weather can expire in 3 days; another about announcing a release should exist forever.
@mro has this right:
#KISS
- you have a codebase default that is set in dev,
- an instance default that can be set by admin
- you have a user account default that can be changed by user,
- then you have a toot default that can be set by user.
These cascade.
Post expires date, (e.g. endTime). Is inherent from the default above if not changed.
We have out of the box working that all user levels are free to change, this is a “native” aproch/outcome. Based on TRUST rather than CONTROL we don’t hardcode anything in to change behaver, this is the power of default, which you are right is a small bit of power
Then on your instance this is CONTROL, on remote instance it is TRUST that they fallow the date embedded in the toot.
Ones the papier plane is in the air you have no actual CONTROL any more, this is the #openweb though you can see the elephants close to you and TRUST them before you through the plane, this is transparenc/ #openprocess #4opens
make it as fiddly as you personally like – you may set every single post (like you adjust the language) or configure a default. Make it 100years which is a bit less thean forever but still more than I will bother with. I personally would take 1 year, prbly. You could even create a client that acts on e.g. keywords. If creating clients weren’t so intricate.
indeed, or why would I have sent them my post?
1 Like
I would call this Reduction to a Harder Problem. In my mind defining trust should be much harder than defining public. Also something being public means, I don’t have to put a lot of trust into the people it is shared with.
In the end social is all about TRUST in a good society, yes you can use CONTROL, but this makes a bad society. The #geekproblem keep pushing CONTROL because they do not understand this simple humane social need.
It’s a problem that is #blocking the coding we actually need, what are your ideas to unblock this?
you don’t have to define it if it’s not a machine duty. Send the post to given recipients (incl. possibly ‘all’) or don’t. It’s as easy as that. All else can be made complex but will only distract from the fact you have no agency other than on your host (if at all). There are no guarantees.
Trust is a social, wet (in the sense of wetware) thing. No operating machine is ever totally trustworthy. Trust may relate to responsibility. We’re far out of technology now. Tech can serve, but not guarantee.
In the end, it’s stunningly simple – many things are simple until we complicate them. But easy solutions rarely convince the crowd. And big tech is obsessed by and thrives on complexity. (see Eric Evans, Don Norman, Steven Krug, etc., I once gave a 5-min talk about such https://mro.name/36c3)
Edit: the “Tools for convivality” are a strong personal influence.
1 Like
Well said @mro
#OMN antidote to this #geekproblem is “if it’s not messy” it’s not worth doing in tech, and we mean messy is a social sense, also use the idea of leaky, all communication and most data should leak to lubricate social needs.
CONTROL and SECURITY in the social sense become the problem that they obviously are.
Now ideas to communicate this to people who think both hard CONTROL and SECURITY are solutions to social realms. Ideas to move thinking to social when the understanding of the world and its squishy bit is in mechanical terms. Obviously this is a balance few people are this DOGMATIC and blind, so the question is more how to shift this balance.
I did some blog post on this http://hamishcampbell.com/?s=control
