#social 2019-09-13
2019-09-13 UTC
# 
melody nightpool[m]: yeah, that still leaves major holes in conversations, i think it's because the same thing doesn't happen if you don't follow people whose replies start subthreads
# melody i have been using a single-user instance for a long time and i can't follow any conversation where i don't follow every participant basically because of this
# melody relays can but don't always help that
# melody i'm not sure if there's a way to make replies-to-replies maintain a thread context in a way that would allow inbox forwarding to cover this case but in practice it doesn't
# melody there also seem to be other gaps in practice, but i don't know enough specifics to diagnose what might be causing them
# 
jaywink[m] inbox forwarding is there for exactly this reason, to ensure context is kept. it sounds like it just isn't implemented correctly if all the replies are not delivered to all participants - maybe because of the microblogging environment?
# jaywink[m] personally I always calculate the root of all replies and use that for context of calculating who should be delivered to (in terms of forwarding replies)
xmpp-social joined the channel
# jesopo nightpool[m]: thnx!
# jesopo so if i have to:[public, followers], there's a better chance their followers will get to see my reply?
# jesopo or followers in the cc?
# mardy dansup: Hi! I'm the author of PhotoTeleport (http://www.phototeleport.com) and was wondering if you have some API documentation for uploading photo. I found https://github.com/pixelfed/pixelfed/issues/1054 but it doesn't say much
# nightpool[m] jesopo: yep!
# jesopo nightpool[m]: to or cc?
# nightpool[m] up to you
# cwebber moin moin
# lain_soykaf is that socialhub thing up, btw?
rigelk joined the channel
# nightpool[m] looks like theoretically
# nightpool[m] ah, it's still being created by whoever was setting it up
# rigelk[m] it should be publicly announced by the next meeting
cwebber and BitBot joined the channel
# lain_soykaf Adding Emoji Reactions to pleroma: https://git.pleroma.social/pleroma/pleroma/merge_requests/1662
cwebber joined the channel
# cjd This "social network from hell" thread is so much fun :)
# lain_soykaf :)
# jesopo when your follow to a locked account is approved, how do you then see the nonpublic toots from before you followed?
# jesopo or does it push the old toots to the new follower's inbox? or
# melody you don't
# melody at least, in practice, in the software i know about offhand, it does not backfill content in that scenario or any other, but it's up to software behavior whether to try -- i am not sure if software that keeps a local cache allows you to see follower-only posts that were delivered to other people on your instance once you become a follower, or what happens if you're on the same instance as somebody with past follower-only posts
# melody but in practice you cannot expect that new followers will be able to see old posts on a locked account
# melody just like you cannot expect that poorly connected accounts will be able to see anything anywhere
# melody these should be solvable problems but they are not practically solved in existing implementations
# lain_soykaf if the posts arrived before, you will see the old posts in pleroma
# lain_soykaf this can happen if somebody has already been following that person and the posts are on the server
# melody this is all unspecified behavior ultimately and there's a reasonable definition of follower-only posts where the software would make the decision not to share with anyone that wasn't explicitly addressed when it was sent
# melody even if the posts arrived
# melody since this isn't something in the spec
# cjd Encryption is a really good way to make a spec get enforced
# cjd Or even just to make it get completely thought out, if you're encrypting messages, in order to make the instances interoperate you actually need to think out all of these details and write them down
# melody maybe, but i think it also would have left a lot less room for innovation or use cases that could drive things in new directions
# melody when you need everything perfect ahead of time it leaves no room for needs you didn't consider
# melody there's a tradeoff
# melody though i think my vision is pretty well at odds with what most people seem to want out of the fediverse
# melody or at least what most people involved in fediverse dev want out of the fediverse
# cjd Is your vision written somewhere (?)
# cjd Or is it not a burdon to explain it to me now ?
# melody no and no sadly, are the short answer versions
# melody i have a lot going on in my head but ultimately i'm approaching things from an anti-harassment and anti-abuse focus as an overriding concern and i've got a lot of ideas for what that means that are largely incompatible both with how the fediverse works now and with the direction i'm sensing it moving
# cjd Ok, I'd really love to hear your ideas - though be warned, I'm sort of a blackhole here because I'm very likely to lose interest in social networking before I ever write any code - but I enjoy talking about things
# melody like, the things that worry me most especially are the movement towards prioritizing censorship-resistance and immutability to support wider distribution of content -- those properties tend to make harassment resilient and it's a desirable set of properties for vanishingly few kinds of content, it feels like a concession to technology over the human interest in general -- its possible to mitigate impact but im skeptical of how it will play out
# cjd Against deletion and expiration you mean ?
# melody so like i see a lot of people are really excited about content being able to survive nodes going down -- i understand why, but hyper-durable public content that nobody can control is not actually a desirable property for me, it makes abuse mitigation functionally impossible
# cjd Oh, I didn't fully grasp this about datashards
# melody datashards is still not fully formed to the degree that it would be impossible to mitigate this, and i think there's probably ways to use it that wouldn't be as risky
# cjd Actually my personal preference is to have an originator of content and have everyone else "agree" not to store it longer than it's http header says to
# melody but it's unclear to me to what extent the practical reality will undermine best efforts to mitigate the risks
# melody censorship-resistant networks are harassment-prone networks historically though
# melody they are breeding grounds for abuse
# melody so im skeptical of big pushes for social networks to be censorship-resistant/hyperdurable
# cjd You might have noticed my current source of amusement being "imagine a social network which maximizes drama", but even then, I'm really not that positive about this data-lives-forever stuff
# melody i think there are limited scenarios where this is a desirable property of content
# melody and things like news publishing might be one of them
# melody and i'm not saying you want to optimize for maximum disposability either
# cjd Sort of a fun thing: https://mastodon.social/@cjd/102784881983978583
# cjd I have multiple directions of thought here: 1. map out the space so we understand what the tools can be 2. maybe in some cases more drama actually makes less
# cjd Anyway, in any system I'm actually going to use, I really don't want data living forever
# melody "a social network that maximizes drama" would probably look a lot like the current microblogging-based fediverse but with publishable anonymous dms and quote-boosting
# melody it's already pretty good at exploding itself three times daily
# cjd I'm making a little document of the *options* which increase drama, I'm not so interested in the stuff which is forced on people because they'll quickly just turn it off
# cjd But I start to think that maybe the way to make things better is to enable, in the UI, bad behaviors which were always available to someone who could write code
# melody i doubt it
# cjd Obvious example being hacked screenshots... currently most people believe them, but if there was a screencap button which first allowed you to modify the post before screencapping it, then nobody would believe them
# cjd Anyway, it's one hypothesis and one which gives me some amusement to think about
# melody i don't think it would change the believability much actually, i think you'd be surprised how context-sensitive it already is whether people will believe them or not, if the screencap is believable people will believe it regardless of how easy it is to fake, especially accompanying a message asserting its authenticity
# cjd hmm
# melody memes based on faking screencaps are already really common on some platforms, so its well known how fake-able they are
# melody people still believe ones purporting to be real
# melody especially if they explain away why they're no longer public by claiming the original was deleted
# melody no way to verify, if it's convincing and in character, people will buy it
# cjd Oh yeaah, I can totally see that happening
# melody "make it really easy to do bad things so nobody will trust anything" doesn't turn out to be a particularly functional strategy, people will make decisions about what to trust anyway, adding friction to doing manipulative things makes it, well...harder to do them, and makes fewer people interested in going to the effort -- that makes the resourced people doing them anyway relatively more dangerous but shrinks the scale of the problem
# cjd hmm
# cjd Oh, I totally am
# cjd When you can increase the friction from the victim side (mostly cryptography), that probably works well... On the agressor side increasing friction is probably going to run into trouble once people figure out how to disable the feature.
# melody you need to attack the problem from both ends in a decentralized network, relatively few attackers are motivated enough to modify the software to disable the features, especially in ways that are undetectable, and unresourced attackers who don't control their own deployments can't modify the stock software, so that protects you from a lot of drive-by harassment that isn't driven by a sophisticated and highly motivated adversary
# melody once you hit "sophisticated and highly motivated" then the protections from the other direction become more critical
# melody but you can get further than you think on simple friction
# melody and social norms
# cjd If there are things which are supposed to be made difficult, that's not really a problem but it needs to be super clearly explained in the protocol
# cjd One drum I've been banging lately is a "pledge" system - where a server makes a pledge to (for example) delete data when requested and to honor expiration
# cjd If the server doesn't make the pledge, you choose whether to federate with it and a user can choose whether their messages should be federated with servers who don't pledge
# cjd but if a server violates a pledge, that's probably something which can be construed as either a GDPR violation or some kind of contractual breach
# melody that's an example of a social norm, and i think those types of systems can work well in semi-open or semi-closed networks, but falls apart for more fully open ones and wouldn't work for something like a p2p network
# melody so i think that depends a lot on what you're trying to accomplish
# cjd Yes, that's why I'm currently pretty negative on p2p and much more positive about federation
# melody i don't think it's really plausible to nail a p2p solution yet, i'm keeping an eye out
# cjd fair point, maybe something comes along, but I'm not that hopeful at this point
# cjd deletion is a Hard Problem
# cjd But I find it really interesting that you and I, approaching social networking with the exact opposite objectives, actually agree on quite a few features