#social 2019-10-11
2019-10-11 UTC
Guest84, sl007, doublequartz, ajordan and xmpp-social joined the channel
# 
lain_soykaf cwebber2: did you get a chance to look at the semantic hint type stuff?
# trwnh cc jaywink[m] and fr33domlover: https://socialhub.activitypub.rocks/t/unresolved-issues-surrounding-follow-activities/114
# trwnh also looking for feedback re: above (Follow Object, Follow subset of actor outbox instead of whole actor outbox)
vitalyster and sl007 joined the channel
# nightpool[m] I'm not sure I exactly understand the difference between adding a second type and just adding a property with the same semantics?
# nightpool[m] is there a good reason to choose one over the other?
# lain_soykaf essentially, it's about using compound types (["Application", "Invisible"]) to give hints on how to treat an actor. In this case, to not show Announces of this actor in the RT list
# nightpool[m] yes
# nightpool[m] I understand the proposal
# lain_soykaf nightpool[m]: i'm wondering the same, I'd lean towards a different solution as well, but nobody else seems to worry and my own worries are a bit diffuse :)
# lain_soykaf nightpool[m]: the previous one wasn't a reply to you :)
# nightpool[m] I mean I'm not worried, per se, but I start every architecture conversation from a position of "is there any reason to do this instead of the simpler, more obvious thing"
# nightpool[m] and in this case there doesn't seem to be?
# lain_soykaf also kaniini is in this channel by now
# lain_soykaf i'm not *worried* worried either, it just seems a bit weird to me so i'd like to get some opinions. There's buy in from pleroma and mastodon for the idea so i'm sure it would be fine to just go along with it.
# 
jaywink[m] Kind of feeling a property would be the simpler solution 🤔
# jaywink[m] * Kind of feeling a property would be the simpler solution as well 🤔
BitBot, sl007 and cwebber2 joined the channel; vitalyster left the channel
# kaniini nightpool[m]: i think this is the better way to do it, because if you think about it, this is really a form of type enrichment
# kaniini jaywink[m]: the goal is to avoid adding dozens of properties to convey specific behavioural semantics
# kaniini by compounding them into the type, we can simply add these hints
# nightpool[m] the type enrichment thing is kind of compelling and I can kind of see it if I squint, but I'm not sure there's a meaningful difference between "adding dozens of properties" and "adding dozens of types"
# melody the distinction between a property and a type is also generally speaking a tossup -- whether invisibility is a property of a thing or whether invisible things are types of things is a modeling problem, i think treating invisibleness as a property is probably more consistent with the other qualities of the way objects have been schematized so far but it's always possible to change that
# kaniini it does not really matter to me which way we go, but i would point out that this seems to be the JSON-LD way to do it
# kaniini however i would like to conclude this one today
# kaniini because it is blocking an MR in Pleroma
# kaniini can somebody with admin access to socialhub please add 'rinpatch' to the Pleroma team? nightpool[m]?
# kaniini i would ping hellekin but they seem to be missing at the moment
# melody i think you could achieve the outcome you want either way in json-ld you would need to include something defining the property in the context, that could be a type or an extension - a litepub terms namespace could serve the same purpose as a set of litepub type definitions at that point - i am not particularly opinionated about how this gets resolved either really
# melody my only concern with compound types is that it may not be clear how types should be combined
# melody invisibility is an easy case maybe but if two types in the compound type end up defining similar properties, you suddenly need to start deciding which ones to show and not show and how to operationalize them, which one should take priority, how to apply mutually incompatible side-effects
# kaniini maybe instead of compounding the type, we have a hints set?
# kaniini and yes if you look at the changes in Pleroma they are kind of ugly to support compounding
# melody maybe? i haven't thought super duper deeply about the set of hints somebody may want to apply - could a hints set of some kind be used to help resolve ambiguity so that we're no longer dealing with like, post visibility being implied by which part of the addressing collections are in?
# kaniini that is likely why lain_soykaf isn't happy about the approach :)
# kaniini yes that's what hints are for in a way
# kaniini but they should not be construed as a security thing
# kaniini followers-only (and also circles) require a form of security delegation to do correctly
# kaniini I would prefer OCAP for this but it has been demonstrated using relaying and LDS
# melody i mean, so does 1-to-1 private messaging, really -- as long as instances have more than one actor, you are relying on a third party not to act maliciously
# kaniini a good analogy for hints instead of post visibility is
# kaniini probably something like group messaging
# kaniini in a group, the group actor does an announce to forward the message to other members
# kaniini but it's not a boost
# kaniini so really these are meant to be hints for how the message should be displayed
# kaniini fixing followers only posts could be done this way but it would not be a robust approach
# kaniini I do have thoughts on that and need to blog about them :)
# kaniini multibox, using audience and detached capability delegation proofs (so the parent instance can redistribute to the original circle) are the way that followers only posts get fixed
# melody right - it was more that currently post scoping is done via a set of undefined rules that aren't actually part of the spec , display hints could help instances handle those comparatively correctly without needing to understand those undefined rules
# melody it's not robust but neither is what's going on now
# kaniini it is helpful as an informative hint I agree
# kaniini I just worry that some may see it as enough and not pursue fixing the actual problems
# kaniini an ongoing problem with getting fediverse projects to do work is that they tend to be a conservative bunch on risk exposure
# kaniini which if you think about it, makes sense. if the software breaks, we get users who are not happy about it
# kaniini and if you've seen how that tends to go, it's not pretty
# kaniini and with the gabs and kiwifarms of the world amongst us, I think now is not a great time to be lax on security
# kaniini so I would be in favor of a visibility hint, on the precondition that vendors agree to tackle the actual security problem as well
# melody Yeah, my approach has been to essentially silo myself off and try to do the right thing, independent of what anyone else is doing, because I've determined that I'm more or less okay if my platform only has interop with other instances of itself, I've got enough weirdness planned I can't expect anyone else to go along for the ride
# melody which has led me to be a little less concerned with some of the existing implementation details
# kaniini an example of what I mean is, Mastodon in the OStatus days used a visibility hint, but did not add a new salmon endpoint
# kaniini so GNU Social just ignored it
# kaniini (some argue that was intentional maliciousness but the reality is that GNU Social just hasn't been properly maintained in years)
# melody i started planning this in the ostatus days but ostatus sucked and i ultimately let it go, the protocol would have been unrecognizable when i was done with it - that may still be true with activitypub but it's flexible enough that i may still technically be implementing it ^_^;;
# kaniini a conformant AP server can ignore the visibility hint, but cannot ignore the calculated audience
# melody yeah, i'm aware - the scoping implications are a consequence of sharedInbox though, right? the recipient server needs to know the implied visibility based on audiences in order to choose how to display what was sent to the people it's delivering to, iirc?
# melody it'd be easier if that was just defined somewhere else and all it needed to know was who to deliver it to and then separately whether it should put it on public timelines or whatever
# kaniini no, but the problem is the use of collections in S2S to begin with.
# kaniini have to run for a bit :)
sl007 and rektide joined the channel