#social 2019-05-28
2019-05-28 UTC
cwebber2 and nicolas-constant[m] joined the channel
# 
fr33domlover What do you think about the Public thing in audience?
# fr33domlover I don't like it much, I wonder if some separate visibility field would have been better
vitalyster and xmpp-social joined the channel
# 
jaywink[m] that is probably how I would have done it myself as well, but probably a bit late for that discussion. I guess if it was not in the audience then what do you put in the audience for something that is public? in that sense it makes sense to have it there even though it feels a bit artificial
# cjslep[m] I prefer a 'visibility' property.
# cjslep[m] Mixing delivery with that concept isn't fun.
# jaywink[m] TBH, I think the whole fact that S2S deliveries have an audience is artificial. The receiver doesn't really need to know who the recipients are. If they've received the object, it is probably intended for them. In that sense a visibility object would be nicer.
# jaywink[m] yep
# jaywink[m] for C2S it makes sense
# cjslep[m] I feel bad cause I'm normally good at reading whole threads, but that one sprung up overnight like my potato plants...
# dansup I started working on Story Polls in Pixelfed, i don't expect this to be compatible with Mastodon/Pleroma because they don't support ephemeral content
# jaywink[m] cwebber argued that sharedInbox was a mistake. I tend to agree that moving from publicInbox to sharedInbox was a mistake. non-public deliveries would be better imho made indfividually
# dansup sharedInbox isn't a mistake IMO
# jaywink[m] I guess it depends on how often you have people with tens of thousands of followers - in that situation yes it definitely is required for scaling
# jaywink[m] (talking about limited visibility content)
# cjslep[m] What I took Chris to mean when he called sharedInbox a mistake is about who is able to see your AP federation -- only you, and the recipient. This is unlike the big federation elephant in the room: email, which has strangers handling your notes in between. In that viewpoint, sharedInbox devolves from APs novel point-to-point federation back to the 70's of a bunch of middlemen handling it.
# jaywink[m] yep for limited visibility content this can be a problem. but for anything that is public - who cares who sees it, it's intended to be public? :)
# cjslep[m] Thing is, 'as:Public' doesn't reflect nor does it carry the user's intentions. Just look at Mastodons use (followers only vs public)
# jaywink[m] only public gets `as:Public` tho?
# jaywink[m] it's more of a UX problem than a protocol problem imho, the suggestion for "authenticatedUser" etc discussion going on IMHO sounds like a good idea - Socialhome would use it, it already has a SITE visibility which though currently doesn't federate basically means "public but not shown unless authenticated". It's more of a UX hint than a promise of privacy if federated though.
# cjslep[m] I don't view anything in AP as a UX problem, that's up to each app when interpreting AP. I view 'as: Public' as a Boolean signal that is abused (today, by Mastodon) to be a tri state signal -- and that third state is a semantic meaning problem. Mastodon has already dictated what 'to' and 'cc' mean for it's tri-states, but each other app could choose something completely different. And then from there a UX problem will arise: Masto shows one way,
# cjslep[m] another app shows a different way. It is pure abuse of an unexpressive, Boolean state signal. Adding another Boolean signal that could be abused, doesn't sound good. In fact, it adds a new dimension of abuse, so you are getting 3^N new semantic meaning problems for N boolean-like signals
# cjslep[m] That's why I prefer the expressiveness of a property instead -- "just say what you mean" kind of philosophy
# fr33domlover dansup, cool!
# cjslep[m] Instead of seeing a magic string in an existing property and having to 1: recognize as a developer, that this magic string in this property 'to' vs 'cc' has special significance, and 2: as an app developer, buy into how everyone else is (ab)using this signal to mean the same thing.
# cjslep[m] ...just have a property 'visibility' whose value can be one from a standard supported list of things, as well as custom add ons just for that developers particular app
# cjslep[m] No semantic meaning problem, so any UX problems then become tractable
# jaywink[m] I agree on a property being better. But I don't understand how Mastodon abuses `as:Public`? Is it added also to "only followers" posts?
# fr33domlover cjslep[m], jaywink[m] , I think I'll implement a visibility thing in Vervis as an experimental proposal, and maybe if I'm lucky, other people will give feedback / follow ^_^ Btw I started writing the ForgeFed spec stuff yay! As to public no-audience just-publish posts, I'd say have empty audience. in AP it means a private message, but what if we have a visibility thing that says who can see the message,
# fr33domlover so empty audience doesn't necessarily mean it's private (or alternatively require as:Public to be used only in 'audience' and not in 'to' or 'cc' etc.)
# jaywink[m] fr33domlover (IRC): 👍
# cjslep[m] If 'as:Public' is in the 'to' property it means "this is truly public and visible on all public timelines" and if it is on the 'cc' it means "this is public but not on the public timelines". These semantic meanings mean nothing to other apps that don't have the same timeline concept in them
# jaywink[m] however, protocols can never unify UX across different platforms. Different platforms might have different ideas of visibility as a concept. For someone public means "only visible to authenticated users" for some "public for all even search engines" <-- me. Once you federate you lose control :)
# jaywink[m] cjslep: wow I didn't know that, that sounds confusing indeed. If I see "as:Public" it means to me "public to post on the web and link on google"
# fr33domlover jaywink[m], we could have an expressive property then, as much as needed to capture the various possibilities and make it reaeasonably extensible to have more :)
# jaywink[m] whether in to or cc - I don't see how that differs
# jaywink[m] it's also not documented in the Mastodon federation docs, might be good to mention
# jaywink[m] fr33domlover (IRC): the biggest issue I see with a visibility property is who defines the visibilities?
# jaywink[m] SH has 4 - SELF, SITE, LIMITED and PUBLIC
# jaywink[m] others will have other ideas :)
# cjslep[m] Right jaywink and now you have a semantic meaning problem. You and I think it shouldn't matter, but Mastodon says it does. That's what I mean by abusing a Boolean signal into a tri state.
# jaywink[m] yep though this is more abusing to/cc to have different meaning I guess
# cjslep[m] I had to change the way my blog federated because of this
# fr33domlover jaywink[m], in Vervis I have an RBAC system so there are roles and access is defined based on them. So we could, say, have a few standard roles, and people could add more, and if you specify a custom role, you can add an a-bit-less-access role that is standard, so that even apps that don't understand your custom role can more-or-less handle visibility
# fr33domlover I haven't tried in actual vocabulary, it's just an idea I will try ^_^
# cjslep[m] And either way, mixing delivery properties (to and cc) with visibility ones is a pattern I personally don't want to see continue
# jaywink[m] yep
# cjslep[m] Sorry I came in full force today. Thanks for letting me ramble at you
# jaywink[m] I think this comes partly due to wanting to keep C2S and S2S very much similar when in fact they shouldn't be. C2S and S2S targeting and delivery are totally different things
# fr33domlover I don't think visibility and and delivery should be mixed neither in C2S nor in S2S :p
# fr33domlover To AP's defense, it doesn't really deal with visibility and privacy
# fr33domlover But I wish it at least did it in a more clean way and didn't have as:Public at all
# fr33domlover Or, roll the sleeves and handle privacy and visibility thoroughly
# fr33domlover I really want to go back to coding ^_^ but pushing myself to write the docs properly before I continue
# jaywink[m] good to get some feedback on the federation stuff before coding too much ;) looking forward to reading about that once you have the draft up to some good state!
# jaywink[m] https://www.abacusnews.com/digital-life/chinese-developers-fear-losing-open-source-tech-trade-war/article/3011463 -- federated forges needed more than ever :P
# fr33domlover jaywink[m], it's very informal so far but I'll paste a link soon :)
# fr33domlover Btw all along I'm still surprised nobody is taking forge federation seriously
# fr33domlover I mean there has been discussion for years
# jaywink[m] yep
# fr33domlover Including on GitLab, which seems so big, and has many full time dev users and community
# jaywink[m] one of my regrets is that I've pushed myself on too many things to be able to help much at all :/
# jaywink[m] yeah for them it would be a killer feature for sure
# fr33domlover I get why GitLab the company won't invest in federation
# fr33domlover Just surprised nobody before me did that
# jaywink[m] nextcloud did get the idea that even file hosting platforms can benefit from talking to each other
# fr33domlover Yeah that's awesome
# fr33domlover Over the years people have complained ocassionally
# fr33domlover about my usage of Haskell to develop a federated forge
# fr33domlover And all along I've been saying, among other stuf, go ahead and write one in Go/Python/Ruby/whatever
# fr33domlover But nobody did
# jaywink[m] I think we've been missing the big push given by AP adoption - now it's just a matter of time before the required extensions are specified.
# fr33domlover jaywink[m], well federation existed in the OStatus days too; when I started working on Vervis in 2015-2016 there was just Ostatus and whatever custom thing pump.io was doing, and I was reading OStatus docs and planning to use it ^_^
# fr33domlover But yeah AP seems to have a wave of adoption
# fr33domlover I hope it keeps getting bigger
# jaywink[m] I never implemnented OStatus, I could never actually find good documentation, but afaik it had huge holes which is why for example mastodon needed AP to move forward. There is Diaspora of course as well, but that has only been cleaned up in recent years and still is limited in the vocabulary it allows and does not even speak of extensions.
# trwnh gotta say it does make more sense to have actor-to-actor be the basis of it... a bit late now that we've built these dependencies on the server model, but it can still be salvaged imo. i think an activitypub 2 should specify stripping to/cc before delivery... maybe use 'audience' for marking which posts are "public", and a 'visibility' to identify the secondary audience who is allowed to view something while not being directly targeted?
# trwnh really the issue to me is that the behavior of as#public doesn't really leave a lot of room for the use cases that people want, the stuff that exists between "i want only my followers to see this" vs "i want everyone in the world to see this"
# jaywink[m] here we go into the age old question of "what is public anyway" and people will always disagree :)
# fr33domlover So, the stuff I've written so far is about authentication, nothing specific to ForgeFed
# fr33domlover Just sharing in case anyone has comments
# fr33domlover And to show the style of the writing so far ^_^ https://dev.angeley.es/s/fr33domlover/r/vervis/s/FEDERATION.md#spec
# jaywink[m] > 503 - Service Not Available
# fr33domlover jaywink[m], eh it crashes sometimes due to a memory leak when serving big files, but automatically restarts after a few minutes
# fr33domlover So try again ^_^
# fr33domlover I should probably figure out a way to stream big files in a constant-memory way
# fr33domlover (Or maybe it's a bug somewhere deeper, the compiler?)
vitalyster and Guest84_ joined the channel; vitalyster left the channel
# trwnh jaywink[m]: people will always disagree because there is no one "public". the different definitions of "public" have different side effects and therefore cannot ever be treated the same
# trwnh it makes sense to explicitly delineate those differing expectations, no?
vitalyster left the channel