From W3C Wiki
Jump to: navigation, search
<cwebber2> =========== MEETING LOGGING STARTS ===========
*** jdormit_mobile (~jdormit_mobile@public.cloak) has quit: Client closed
<sumanah>  [11:03]
<cwebber2> scribenick: dmitriz
<sumanah> today's meeting:
*** jdormit_mobile (~jdormit_mobile@public.cloak) has joined channel #social
*** eprodrom (~eprodrom@public.cloak) has joined channel #social
<eprodrom> present+
<dmitriz> first topic: sec: prefix
<melody> present+
<cwebber2> present+  [11:05]
<dmitriz> eprodrom: there's an outstanding issue for security prefix, so maybe
          I can talk a bit about that
<cwebber2> present+ sumanah
<cwebber2> present+ sandro
<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  [11:06]
<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
<eprodrom>  [11:07]
<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)  [11:08]
<dmitriz> eprodrom: so the question was whether we should jump ahead & include
          the entire sec: vocabulary in there
<cwebber2> q+
<cwebber2> ack cwebber2
<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  [11:09]
<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  [11:10]
<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  [11:11]
<dmitriz> cwebber2: the alternate route is that you can recursively include
<eprodrom> +1
<dmitriz> cwebber2: so that's my summary, opening it to the floor
<cwebber2> dmitriz: which option is evan proposing?  [11:12]
<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.  [11:13]
<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  [11:14]
<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
<cwebber2> +1
<eprodrom> +1
<dmitriz> +1
<dmitriz> cwebber2: and if I don't respond on it, please ping me before the
          meeting.  [11:15]
<dmitriz> cwebber2: ok, good to go
<dmitriz> eprodrom: will take it as a task for next meeting.
<dmitriz> next topic:
*** gluedtothescreen (~gluedtothescreen@public.cloak) has joined channel
<cwebber2> #TOPIC Chris Webber is diving headfirst into some next-generation
           federated social web stuff, but wait what does any of that mean
<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)  [11:16]
<dmitriz> cwebber2: instead, I'm switching to full time on federation stuff,
          and then doing some occasional contracting on the side  [11:17]
<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  [11:18]
<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  [11:19]
<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
<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
<dmitriz> cwebber2: what we're seeing right now is sort of a
          nation-state-ification of the fediverse  [11:21]
<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
*** jdormit_mobile (~jdormit_mobile@public.cloak) has quit: Client closed
    connection  [11:22]
<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: we currently have this assumption (imported from
          FB/Twitter/email) that you have /one/ identifier that's you  [11:23]
<dmitriz> cwebber2: whereas in fact, people have many different avenues to be
<dmitriz> cwebber2: so like, I have a public profile. and then I create
          several different shells for that, that I hand out to different
<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  [11:24]
<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
<dmitriz> cwebber2: and I'm handing somebody a capability to add things but
          not remove them  [11:25]
<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  [11:26]
<cwebber2> ack eprodrom
*** jdormit_mobile (~jdormit_mobile@public.cloak) has joined channel #social
<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
<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  [11:28]
<dmitriz> cwebber2: as far as ACLs - you're probably familiar with it from
          Unix. if you launch Solitaire, it runs as /you/, as the user
<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  [11:29]
<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  [11:30]
<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  [11:31]
<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)  [11:32]
<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: now I create /another/ object, which just forwards the
          messages/activities to it to the original key object  [11:33]
<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  [11:34]
<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 decentralized/secure
<dmitriz> cwebber2: and you can basically only have 2 out of the 3  [11:35]
<eprodrom> I need to jump out to get to my next meeting
<eprodrom> Thanks all!
*** eprodrom (~eprodrom@public.cloak) has quit: ""
<dmitriz> cwebber2: there's a way to get around this (2 out of 3) limitation,
<dmitriz> cwebber2: by making changes to ActivityPub clients, not necessarily
          the spec  [11:36]
<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  [11:37]
<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?  [11:39]
<dmitriz> cwebber2: ok, so, I have a bunch of different ideas and I'm jumping
<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  [11:40]
<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)  [11:41]
<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?  [11:42]
<dmitriz> cwebber2: so it's not like you can't talk to each other outside the
          groups  [11:43]
<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
<dmitriz> sandro: so I can give a different number to the fanfic group  [11:44]
<dmitriz> cwebber2: right! and you can later choose to expose your personal
          phone #, not the fanfic-specific one
<cwebber2> dmitriz: allow me to join in
<cwebber2> dmitriz: the fediverse one, creating new identifiers is very cheap
<cwebber2> dmitriz: combined with decent ui you create these derived
           identities quickly and painlessly and they help limit moderation
<dmitriz> sandro: can you give another example from irl / history?  [11:46]
<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  [11:48]
<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*  [11:49]
<dmitriz> cwebber2: let's say there 2 ways you can find me.
<dmitriz> cwebber2: lets say like, TOR onion addresses, or IP addresses, or
<dmitriz> cwebber2: one of them is a DNS Petname in your system, which you can
          query to resolve into that onion address  [11:50]
<dmitriz> cwebber2: but the /other/ way is - you can only find me by talking
          to Sandro
<dmitriz> cwebber2: so, DNS and Sandro are equal participants
<cwebber2> sandro => Chris Webber
<cwebber2> dns =>
<dmitriz> sandro: I'm getting hung up on the term "petname"  [11:51]
<dmitriz> sandro: is likely not gonna get accepted by other communities /
<dmitriz> cwebber2: yeah, it's.. hotly debated
*** vt (~vt@public.cloak) has left channel #social
<dmitriz> cwebber2: for example, browser bookmarks are petnames  [11:53]
<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  [11:54]
*** vt (~vt@public.cloak) has joined channel #social
<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  [11:55]
<dmitriz> melody: it seems like there are systems where you can /suggest/ what
          one should do with that post
<dmitriz> melody: and I'm not seeing how that works without an identity
<dmitriz> cwebber2: ocap community says: "we don't prohibit what we can't
          prevent", though I'd like to say "we don't /pretend/ to prohibit
          what we can't"  [11:56]
<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)  [11:57]
<dmitriz> cwebber2: so, the OCap community has this idea/system named "Horton"
          (as in, now we know who done it)  [11:58]
<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"  [11:59]
<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  [12:00]
<dmitriz> cwebber2: ok we're at the top of the hour  [12:01]
<dmitriz> cwebber2: happy to do this again next week, same time
<dmitriz> melody: maybe I can ask my questions on IRC later
<cwebber2> =========== MEETING LOGGING ENDS ===========  [12:02]