#social 2018-10-10
2018-10-10 UTC
ahihi2, Loqi_, ahihi, jdormit_mobile, Guest84, vt, xmpp-social, cwebber-specops, dmitriz and sumanah joined the channel
# 
dmitriz I have a general Mastodon question. does it matter which server one signs up with? can you still follow people on other servers?
jdormit_mobile joined the channel
# nightpool[m] this is not really a good place to ask general mastodon questions.
# nightpool[m] we're also about to have a meeting, fyi.
# dmitriz ok, excellent
# dmitriz w00t
# sumanah today's meeting: https://www.w3.org/wiki/SocialCG/2018-10-10
jdormit_mobile joined the channel
eprodrom joined the channel
# eprodrom present+
# dmitriz first topic: sec: prefix
# melody present+
# dmitriz eprodrom: there's an outstanding issue for security prefix, so maybe I can talk a bit about that
# dmitriz eprodrom: where we got stuck last time, and where we can hopefully get to this time
# dmitriz present+
# dmitriz eprodrom: we have a system for ActivityPub for signing requests, using HttpSignatures
# dmitriz eprodrom: has become the standard way for server-to-server authn (for push, sending messages, etc)
# dmitriz eprodrom: we're using this external namespace (the W3C Security namespace)
# dmitriz eprodrom: somebody brought up the issue the last time, that it would not be sufficient to just drop in the sec: namespace (because of id parameters)
# dmitriz eprodrom: so the question was whether we should jump ahead & include the entire sec: vocabulary in there
# dmitriz cwebber2: I agree with puckapedia (sp?) here. one of the things that the context provides is an unambiguous way to map the type that the term provides
# dmitriz cwebber2: same thing applies to IDs. linking to another object, how do you tell that it's just a string, or it's a URL? the context provides a default defn that can be overridden
# dmitriz cwebber2: things like, 'any time you see this, it's gonna be an id'.
# dmitriz cwebber2: if you're using Linked Data Signatures, it does pay attention to contexts of this type
# dmitriz cwebber2: (meaning, the generated hash will be different depending on how it resolves)
# dmitriz cwebber2: so, two ways to resolve it. either we add a namespace to the context, and then for all the terms we want, we copy & paste them in
# dmitriz cwebber2: the alternate route is that you can recursively include contexts
# eprodrom +1
# dmitriz cwebber2: so that's my summary, opening it to the floor
# dmitriz eprodrom: let's take the terms as we need them, that's how we did it in other contexts
# dmitriz cwebber2: lets move it to proposal.
# dmitriz eprodrom: I think what we need is publicKey, publicKeyPem, and maybe owner also?
# dmitriz cwebber2: I'm willing to look at the issue, if that helps
# dmitriz eprodrom: yeah, we haven't looked exactly at which ones
# dmitriz eprodrom: what I'll do is make a PR that includes the Security namespace (so that's available), and then for the current properties, I'll give aliases for those (including types)
# dmitriz eprodrom: and then maybe at the next meeting, we can vote on the PR
# eprodrom +1
# dmitriz +1
# dmitriz cwebber2: and if I don't respond on it, please ping me before the meeting.
# dmitriz cwebber2: ok, good to go
# dmitriz eprodrom: will take it as a task for next meeting.
# dmitriz next topic:
gluedtothescreen joined the channel
# 
cwebber2 #TOPIC Chris Webber is diving headfirst into some next-generation federated social web stuff, but wait what does any of that mean https://octodon.social/@cwebber/100866264755512782
# dmitriz cwebber2: the high level is - I was previously doing a full time job and a half (basically, stuff I was doing for work, and then half-time for stuff in the federation space)
# dmitriz cwebber2: instead, I'm switching to full time on federation stuff, and then doing some occasional contracting on the side
# dmitriz cwebber2: I'm not at risk at being kicked out on the street. I'm trying to push forward with some important stuff. (the thread has some of it)
# dmitriz cwebber2: feel free to ask questions, and I'll attempt to answer
# dmitriz cwebber2: ok, so, firstly part of the goal here is - I'm taking on a tried-and-true approach of making and interesting Skunkworks of sorts
# dmitriz cwebber2: every now & then, somebody tries to make a giant decentralized game, and regardless of whether they succeed, interesting things come out of it
# dmitriz cwebber2: examples - google earth, etc
# dmitriz cwebber2: I've been researching for a while about some of the ways to push ActivityPub spec into new areas
# dmitriz cwebber2: for example, I'd like to change the way we're approaching abuse and moderation tooling
# dmitriz cwebber2: I think right now the current approach is, if you think about programming scope systems (like a Python approach) is - you've got your Global community, and you've got your local instance. so, globals and locals
# dmitriz cwebber2: so, this gives incentive for people to run their local space
# dmitriz cwebber2: like, you can start a group for a community you care about
# dmitriz cwebber2: but that also has some downsides. if you have somebody a part of several groups (not just a global and an individual group),
# dmitriz cwebber2: different groups need to protect them in different ways
# dmitriz cwebber2: relying on instance-level mods tends to exhaust them
# dmitriz cwebber2: we've been seeing some of this stuff on Mastodon. (which has really good, historically, moderation tooling)
# dmitriz cwebber2: but say somebody's a member of both the Fanfiction community, also a member of their professional community, and also like lgbt community
# dmitriz cwebber2: each one of those might have different moderation requirements
# dmitriz cwebber2: what we're seeing right now is sort of a nation-state-ification of the fediverse
# dmitriz cwebber2: like, "I have this code of conduct, and you have one, so let's just ban that instance"
# dmitriz cwebber2: it's getting to the point where it's easier for instance admins to just connect to a whitelist of instance
# dmitriz cwebber2: so there's various instances at war
# dmitriz cwebber2: whereas in fact, the different instances just serve different moderations needs for the user
# dmitriz cwebber2: so I want to move to the assumption that the moderation is not happening on instance level
# dmitriz cwebber2: the assumption is, each person is on many different groups & servers
# dmitriz cwebber2: example, mailing lists
# dmitriz cwebber2: I'm a member of many different lists, which all have different policies, depending on their needs
# dmitriz cwebber2: another core idea that everyone can message you opens up the idea of Dogpiling real easily
# dmitriz cwebber2: example, you post some message, another group doesn't like it, and you get jumped and get all these messages
# dmitriz cwebber2: whereas in fact, people have many different avenues to be contacted
# dmitriz cwebber2: so like, I have a public profile. and then I create several different shells for that, that I hand out to different people
# dmitriz cwebber2: and the moderation system may be different based on what instance you're going through
# dmitriz cwebber2: for example, I hand a shell to Evan, and the moderation is that his computer needs to do some sort of hash/proof-of-work in order to send me a message
# dmitriz cwebber2: later on, I can hand him the ability to just message me directly, without any PoW
# dmitriz cwebber2: another thing to consider: if you have a collection - let's say you're running a conference, and want to curate some images
# dmitriz cwebber2: and I'm handing somebody a capability to add things but not remove them
# dmitriz cwebber2: so, this whole design is taken from the world of Object Capabilities (OCaps)
# dmitriz cwebber2: pause for any questions re OCaps
# eprodrom q+
# dmitriz eprodrom: I'd be interested to hear the user side of this, before the implementation side
# dmitriz cwebber2: yes, I have that, let's get to it shortly though
jdormit_mobile joined the channel
# dmitriz *oh whoops, that wasn't evan asking re user side*
# dmitriz cwebber: I'm working on access control policies based on OCaps.
# dmitriz cwebber2: objects meaning actors.
# dmitriz cwebber2: the OCap community has a metaphor that might be useful
# dmitriz cwebber2: let me give the metaphors, then get back to user experience
# dmitriz cwebber2: one usecase that's commonly described in Ocap community is that we have two fundamental forms of access control - 1) Access Control Lists (ACLs), and 2) Object Capabilities
# dmitriz cwebber2: Object Capabilities are more like car keys. like, if you come up to a car. instead of identity based access control (say, the car scanning your face), it's using /possession/ based access control
# dmitriz cwebber2: meaning, whoever has the key has access
# dmitriz cwebber2: let's say I'm driving the car, and I want to lend it to Alice, but I want to be able to revoke access later
# dmitriz cwebber2: so I hand her a key, but it's "attenuated" in some way, meaning, I can limit or revoke the access later
# dmitriz cwebber2: so let's say she drives the car somewhere, comes up to a Valet service, and wants to limit the valet's capabilities
# dmitriz cwebber2: so she can narrow the key's power even further. she creates a derived object from the key, and gives it to the valet
# dmitriz cwebber2: and it has more limitations - it can only drive X amount of miles, and it doesn't give access to the trunk
# dmitriz cwebber2: a good way of thinking about it is - the way we currently program
# dmitriz cwebber2: if Alice is an object (in an OOP sense, for example) with a 'drive()' method, I can hand her a wrapped key object that limits the key's capabilities
# dmitriz cwebber2: basically, it allows an object to maintain its own state
# dmitriz cwebber2: how do we apply this to actors? (since Activity Pub is an actor-based system)
# dmitriz cwebber2: so I can create a Car object. it gives me absolute control over the car. we can give this car a Capability URI, or an OAuth type bearer token
# dmitriz cwebber2: so you can't drive the car unless you have the (unguessable) credential - the url or token
# dmitriz cwebber2: this is not adding anything to the AP spec
# dmitriz cwebber2: it's just assuming that sufficient security mechanisms are already in place
# dmitriz cwebber2: so that's the general idea. what you have possession of is what you can do
# dmitriz cwebber2: you maintain your own space. make decisions on what to forward or not. and objects & actors can coordinate with others to be able to do rich things
# dmitriz cwebber2: to be able to drive the car (or message me), how on earth do you have a user experience that makes that possible?
# dmitriz cwebber2: if you're familiar with Zooko's Triangle, it says that names/identifiers have 3 properties:
# dmitriz cwebber2: globally unique, human-readable, and unguessable
# dmitriz cwebber2: and you can basically only have 2 out of the 3
# eprodrom I need to jump out to get to my next meeting
# eprodrom Thanks all!
# dmitriz cwebber2: there's a way to get around this (2 out of 3) limitation, though
# dmitriz cwebber2: by making changes to ActivityPub clients, not necessarily the spec
# dmitriz cwebber2: think of your phone's contact list
# dmitriz cwebber2: you can call me without actually memorizing my number. the phone mediates that
# dmitriz cwebber2: and if there's multiple Chrises, the phone contacts list lets you de-ambiguate (like this is SocialCG Chris, and that one's some other chris, etc)
# dmitriz cwebber2: there's other details
# dmitriz cwebber2: like introductions / suggested names and so on
# dmitriz cwebber2: questions so far?
# dmitriz sandro: what my actual question was, let's imagine you're implementing this on Twitter
# dmitriz sandro: meaning, all of this is opaque & behind the scenes, except for what the users are actually interact with.
# dmitriz sandro: so, how would the UX actually be different, with this tech?
# dmitriz cwebber2: ok, let's say Twitter has a global user registry
# dmitriz sandro: wait, I'm not talking about identifiers
# dmitriz sandro: the pain points you started with are things like dogpiling
# dmitriz sandro: and various painpoints in moderation. so how would you improve current (say Twitter style) moderation, with these identifiers and ocap and so on?
# dmitriz cwebber2: ok, so, I have a bunch of different ideas and I'm jumping around
# dmitriz cwebber2: in the group scenarios (on Twitter), if you wanted to join the fanfic community, you send a join request to the fanfic group
# dmitriz cwebber2: and then they either accept/reject, and then your client filters how you're getting messages from that
# dmitriz cwebber2: let's shift now to Mastodon, where the way we currently interact with people is by Webfinger
# dmitriz cwebber2: so, you'd have a similar group type thing
# dmitriz cwebber2: so, I can join the fanfic community on Bob's server, and Dmitri can join it on some other server, and we can communicate
# dmitriz cwebber2: and the administrators of the group can moderate on the group level. (instead of server level)
# dmitriz sandro: as a user, I don't want to care about what instance I'm on
# dmitriz sandro: so is the idea that you limit conversation to particular moderated spheres. do I have the right model?
# dmitriz cwebber2: so it's not like you can't talk to each other outside the groups
# dmitriz cwebber2: more that - you can specify what kind of communications you can request based on which group it comes through
# dmitriz (er, what kind of communications you can receive, not request)
# dmitriz sandro: ok, so like.. a physical metaphor is having multiple phone numbers
# dmitriz sandro: so I can give a different number to the fanfic group
# dmitriz cwebber2: right! and you can later choose to expose your personal phone #, not the fanfic-specific one
# dmitriz sandro: can you give another example from irl / history?
# dmitriz dmitriz: well in general, we're used to having context-specific personas. in the context of the pub, in the context of work, etc
# dmitriz sandro: getting back to the goal here, it's up to the employer to police the interactions via the work phone number
# dmitriz sandro: like, if I get harassed over my work number, the employer can defend, etc
# dmitriz sandro: so, ok, good analogy
# dmitriz cwebber2: ah, so that brings up the notion of "Pet Names", this idea of mapping identifiers to entries on a contact list
# dmitriz cwebber2: so like, here's my work phone, and it's labeled as "My Work Phone"
# dmitriz *not sure I'm following this explanation, re DNS etc*
# dmitriz cwebber2: let's say there 2 ways you can find me.
# dmitriz cwebber2: lets say like, TOR onion addresses, or IP addresses, or whatever
# dmitriz cwebber2: one of them is a DNS Petname in your system, which you can query to resolve dustycloud.org into that onion address
# dmitriz cwebber2: so, DNS and Sandro are equal participants
# dmitriz sandro: I'm getting hung up on the term "petname"
# dmitriz sandro: is likely not gonna get accepted by other communities / contexts
# dmitriz cwebber2: yeah, it's.. hotly debated
vt left the channel
# dmitriz cwebber2: for example, browser bookmarks are petnames
# dmitriz cwebber2: extending bookmarks to have some of these further petnames mechanisms protects from phishing
# dmitriz cwebber2: are there any other questions? I'm only touching on a fraction of my ideas here
vt joined the channel
# dmitriz melody: all of this stuff about OCaps seems to have a limitation, compared to ACLs
# dmitriz melody: it seems like once I have given a post to somebody, let's say, they can do whatever they want with it
# dmitriz melody: and I'm not seeing how that works without an identity handshake
# dmitriz cwebber2: so for example, I'm a private individual, and I hand you a capability to write to my timeline. and I say "please don't delegate that, though"
# dmitriz cwebber2: (and let's take as given, as current research suggests, that it's not even theoretically possible to limit what you can do with something, in an unconfined environment)
# dmitriz cwebber2: so, the OCap community has this idea/system named "Horton" (as in, now we know who done it)
# dmitriz cwebber2: it's basically combining capabilities with access logs
# dmitriz cwebber2: so we can examine it and see who's abusing a resource, and we know who to hold accountable
# dmitriz cwebber2: there's another concept of "split contract"
# dmitriz cwebber2: which is basically - there's a cheap/automated way to enforce a contract (like current smart contracts, etc). but then there's also a way to bring humans into the loop (say, the court of law), that's the fallback, that's the other half of the split contract
# dmitriz cwebber2: ok we're at the top of the hour
# dmitriz cwebber2: happy to do this again next week, same time
# dmitriz melody: maybe I can ask my questions on IRC later
jdormit_mobile, vt, tantek and dmitriz joined the channel; vt left the channel
# heluecht[m] I have a question concerning moderation: on Friendica and Diaspora a thread owner can delete a comment of another user when this had been a comment on the owner's thread.
# heluecht[m] Could this be done with AP as well?
jdormit_mobile joined the channel
# melody i don't think so, not in any super reliable way but i think it's theoretically possible
# heluecht[m] This deletion had to be distributed as well. So actor A would request the deletion of a post from actor B - which normally should be prohibited.
# JasonRobinson[m] it only works in the diaspora protocol because it is agreed to be honoured. it's not actually documented in the protocol currently
# heluecht[m] This would be a problem, since you had to create a tombstone for a foreign server.
jdormit_mobile joined the channel
# melody right, but you could implement it using collections over AP if you wanted, so that you could layer on more access control, so a thread would be a custom collection owned by the creator, which could have its own logic for who to accept or not accept delete activities from, and then you could federate that (by choosing whether to forward it to the other thread participants/etc) at the originating server
# melody that approach wouldn't be super compatible with existing implementations
# melody but that wouldn't (shouldn't?) break spec
# melody and a similar approach would be needed if you wanted to implement, for instance, something like a forum on activitypub
# melody where you'd be reifying threads as their own kind of collection with their own valid interaction types
# melody rather than distributing pure posts
# melody that's why the short answer was "i don't think so" and "not in any reliable way"
# melody but you can do a lot with custom collections/custom object types
# melody and you start to have to, once you want to do anything with activitypub besides a microblogging site
# rialtate[m] With our groupware we couldn't figure out any reliable way to have a consistent ux with existing impl so we went with Announcing foreign AP actor posts as a form of group "distribution". So the author has control of their post directly, if we wanted to mute it, the Announce could theoretically be deleted but we withhold the announce until moderator approval instead in our current workflow.
jdormit_mobile and dmitriz joined the channel