#social 2018-04-24
2018-04-24 UTC
# 
dansup I'm kinda new to the scene, does anyone know why the dev of postActiv is so negative towards mastodon and activitypub?
# xmpp-social [ajordan] AP, I think because of the W3C's DRM standardization efforts. IIRC, not sure.
# dansup She posted http://archive.li/JnNMc and I have no idea why she spreads lies about certain developers.
# xmpp-social [ajordan] Dunno about Mastodon
# dansup ajordan: This is what she said about AP, its really sad http://archive.is/05huT
# xmpp-social [ajordan] Wow. That's... something
# dansup I've called her out, but she continues to ignore me (https://mastodon.social/@dansup/99911508625690248) but still merges my gnu/social code into postActiv lol
# dansup Thought I would bring it to everyones attention since she is spreading lies about ActivityPub and people because she can't or won't take time to write code and fix the numerous bugs in postActiv.
mahmudov, fr33domlover, xmpp-social, bitbear, dwhly, jondashkyle and DenSchub_ joined the channel
# JanKusanagi \o/
cdchapman joined the channel
# saranix isn't mastodon a fork of gnu social?
# saranix oh
# saranix still... doesn't seem very groundbreaking
# saranix meh... it's a web standard. anyone who's got browser is "into the network"... heh
# lain would be nice to have
# lain not all networks are planning to keep ostatus support around forever
fr33domlover joined the channel
# Gargron dansup: that screenshot looks good
# Gargron also don't worry about mayiannah, pA is little more than reskin and some refactor of GS, it always surprises me when people even list it as some separate project
# Gargron cwebber2: do you have opinions about how steps 1 and 2 would be expressed? https://github.com/w3c/activitypub/issues/300#issuecomment-383957293
# fr33domlover Anyone knows why postActive is a fork and doesn't merge into GNU Social?
# fr33domlover *postActiv
# Gargron in my understanding the answer to that is political
# fr33domlover Gargron, what sort of political?
# fr33domlover Did GNU Social maintainers reject a patch etc.?
# lain GS was pretty dead for while
# lain with patches not getting merged
# lain it's more active now
cwebber2, cwebber, cdchapman and Emelia joined the channel
# cwebber Hello Emelia !
# Emelia Hi!
# cwebber I'm assuming you're the person I was chatting with :)
# Emelia Yes, emelia@switter.at
# cwebber horray
# cwebber Gargron: fyi I'm still replying to your post! I haven't forgotten! I got off my standards call just a bit ago.
# Emelia yeah, setting up mumble must've done something to my audio >_<
# cwebber sorry :(
# cwebber anyway, so nightpool, Emelia and I were discussing https://switter.at/@MistressEmelia/99914831481031093
# cwebber so Emelia is talking about invites and a mutual-consent web of trust
# cwebber but Emelia I think it would be helpful if you could type out your use case :)
# Emelia Yeah, so, this is basically stemming from a thing that sex workers need to improve safety
# Emelia Essentially, we used to have tools which said "do not see this person" or "this person has references X, Y, and Z"
# Emelia however, all those were hosted in the US, and were shutdown due to FOSTA/SESTA, despite being relied on by an international community
# cwebber Emelia: so basically sharing a web of trust/distrust?
# Emelia So, the idea is to build a new open-source tool for verification & web of trust/distrust
# cwebber cool
# cwebber Emelia: so... I think there may be two/three ways to do this
# Emelia however, we have an existing social problem in sex work known as "reviews" from "hobbyist" culture — essentially a coercive force
# cwebber Emelia: oh ok before I talk further could you explain that?
# Emelia so, what ever new system we design has to have both parties consenting to any interaction
# cwebber I see
# cwebber ahhhh
# cwebber ok
# Emelia Sort of like how I could invite you to loads of github repos without your consent to try and harass you, this has similar
# cwebber Emelia: right right
# Emelia If I say I've met you, and you can't refute that, then I have the power
# Emelia (which is presently how all the review culture and hobbyist systems work in sex work: the power is with the reviewer rather than the worker
# cwebber Emelia: so I have a few directions that I could suggest this could go, but first maybe you should lay out the direction you were thinking with Invite/Accept/Reject/Ignore
# Emelia Yeah, so, the general idea is to have a system of federated servers, each having a copy of all the data.
# Emelia John can create a "I've met this person" relationship to Sally, and that's an Invite for Sally to accept
# Emelia On John's profile, it'll show that he's sent a request to sally indicating he's met her, but hasn't yet received a response
# Emelia If sally accepts, then both profiles show them as having met
# cwebber Emelia: just as a sidenote, Evan Prodromou (who was responsible for a lot of ActivityPub's design) gave a talk about how/why a dating site could be done in ActivityPub https://slides.com/evanpro/dating-on-the-open-web-7
# cwebber may be some ideas to mine
# cwebber I know this is not exactly "dating site" but there are connections
# Emelia If sally declines, then from John's profile, you can see he sent sally a "I've met" request, but she refuted that
# Emelia The idea of this is to ensure that people only send "I've met" requests to people they've actually met
# cwebber Emelia: here's another question: do you want this to be a completely open, all entities have all data system
# Emelia yes
# cwebber or should it be that entities who have introductions to each other see the data
vasilakisfil joined the channel
# Emelia because at the moment, we had systems that were silos, and that caused issues because they can disappear overnight, taking with them all the verification information we relied on
# cwebber Emelia: I absolutely agree that there shouldn't be silos
# cwebber however there are two choices that both do not require silos
# Emelia If John wants to see me, I should be able to see everyone who John has met, and everyone he says he's met
# cwebber one of which is basically a large, collaborative ledger (I'm trying really hard to avoid the word "blockchain" here, but it's a collaborative distributed database)
# cwebber the other one is effectively a whisper network
# Emelia (there's a second part to this which is, extending from has met / hasn't met, there's recommends / doesn't recommend (only if you've met)
# cwebber we share connections, but only if we know each other
# Emelia I've been erring more towards the blockchain style system
# Emelia (it has the added benefit of being immutable)
# Emelia A lot of this is based on ideas discussed in the intimate.io whitepaper, however, apparently they're 3 years away from building any of that functionality, and we kind of need it yesterday
# cwebber Emelia: right, ok
# cwebber Emelia: so, ActivityPub is more for the sending messages directly from party to party, and in that sense it may not be the best fit for a blockchain style system, but maybe I'm wrong
# cwebber but
# cwebber there is another way to do it that actually uses related datastructures
# cwebber and is being explored by some people working on Decentralized Identifiers (DIDs)
# cwebber however it relies throwing even more tech into the mix and I'm nervous about overwhelming the space
# JanKusanagi DIDs and DIDNTs? :D
# cwebber especially because it's tech that's still very much so in progress
# cwebber JanKusanagi: heh :)
# cwebber so here are two components:
# cwebber so if we imagine a person, let's call her Alyssa
# cwebber and she has a number of properties on her
# cwebber we can imagine that as a record
# cwebber with a series of slots for here's my name, my inbox, etc etc
# cwebber well, in linked data anyone can say anything about anything, but as Emelia is saying
# cwebber it's extremely important that we know *who* is saying *what* about *whom*
# cwebber https://w3c.github.io/vc-data-model/ the Verifiable Credentials data model allows you to "extend another person's record"
Emelia_ joined the channel
# cwebber so if some university hands Alyssa a degree
# Emelia_ sorry, internet troubles
# cwebber np
# cwebber https://chat.indieweb.org/social
# cwebber chat logs in case needed
# cwebber so anyway, if Alyssa's university wants to say she has this diploma
# Emelia_ has caught up
# cwebber
{"issuer": "https://foo-university.org/", "claim": {"id": "https://social.example/~alyssa", "graduatedFrom": "Foo University"}, "proof": {... signature from foo-university here}}# cwebber so as you can see, even if you go to https://social.example/~alyssa normally and don't see the graduatedFrom
# cwebber Alyssa's university was able to extend her record
# cwebber now Alyssa could also countersign this with her own key
# cwebber ("proof" is basically "signature")
# Emelia_ ok
# cwebber Emelia_: I'm sorry, am I going off in abstract land?
# cwebber I'm always nervous about that
# Emelia_ not really — the only thing I'm worried about is the end user needing to know any of this
# cwebber Emelia_: ideally the application would be written in such a way that the user wouldn't need to know anything right?
# cwebber the application would do it for them
# Emelia_ yeah
# cwebber the other spec that may be of interest is https://w3c-ccg.github.io/ocap-ld/ which is verrrrrry WIP, but object capabilities are a way that you can programmatically consent for an entity to do something related to them
# Emelia_ Some of the people we're having use this system are extremely non-technical, so it has to be simple enough that they understand it
# cwebber yes
# cwebber I think I'm going too far in future tech land
# cwebber Emelia_: part of the problem is you started to suggest a blockchain'y direction and I'm not sure ActivityPub is totally set up for that but maybe I'm wrong
# Emelia_ I'm more just looking for a way for multiple servers to share this information
# cwebber fair
# Emelia_ or multiple clients
# cwebber Emelia_: so, one could also say that if each server is signing each request
# cwebber then you can always replay the Invite, Accept, Ignore
# cwebber etc
# Emelia_ (i.e., there's no reason why we even need servers)
# cwebber going back to your original idea
# cwebber so if you're willing to throw out the merkle tree in favor of doing things closer to how activitypub is used today
# cwebber you can still distribute and share the original objects
# cwebber however it might not be a shared database
# Emelia_ hm, I think having a shared database is probably beneficial
# cwebber Emelia_: oh I agree it's a good thing to explore and may be a good fit for this use case :)
# Emelia_ i.e., you wouldn't want to go to the wrong server and see the wrong information, that then leads you to harms way
# cwebber right
# cwebber or outdated info
# cwebber if someone retracts something
# Emelia_ yeah
# Emelia_ not only that, but the idea is that the hasMet would be multiple times
# dansup is this about user verification?
# Emelia_ @dansup kind of
# Emelia_ @dansup it's about establishing trust & maintaining a record of who knows who in a totally distributed fashion
# cwebber Emelia_: as a side note, I think recent developments of using ActivityPub over tor onion services and peertube style using content addressed storage may be useful in your use case
# dansup Interesting, kind of like keybase but distributed?
Emelia joined the channel
# Emelia yeah, quite like keybase
# cwebber well keybase is basically taking the web of trust model and centralizing it, so ;)
# cwebber however hopefully now that we have social networks, web of trust systems don't need to mean a bunch of nerds signing each others keys at a conference
# Emelia only problem is keybase only has a certain number of services it supports too (i.e., I can't verify I'm mistressemelia@switter.at with keybase)
# dansup The idea of 3rd party verification using crypto proofs is interesting to me, I was wondering how to do something similar for my project. It would be more like "Verified as X on keybase" where one could use keybase or any services with a means of posting/verifying proofs
# Emelia yeah, that's more "verify X on Y is actually also X on Z"
# Emelia which is a little more involved (because you need a way for automatic the checks for proofs and stuff in a good manner)
# Emelia but the basic idea of a distributed database of all this would in theory be able to be extended with different events (e.g., Sally added proof of switter.at, proof verified at X date, proof removed at Y date)
# Emelia then you get into another world of troubles of "what happens if identity provider X disappears? do I loose all my previous 'relationships'? "
# fr33domlover Once I tried to design some model for representing information, kind of like RDF,
# fr33domlover And I decided to play with the idea that identities are separate entities
# fr33domlover They shouldn't encode any information
# fr33domlover e.g. you are still you even if you change your name, address and website etc.
# fr33domlover So I used random UUIDs as identifiers instead of URIs or anything like that
# fr33domlover Namespaces and labels still existed, but they are just a layer on top for humans to use
# lain you could do AP over something random right now, if you do p2p over a dht.
# fr33domlover DHT is nice for federation is more than 1 way
# fr33domlover It would be cool if federating servers maintained a DHT together
# cwebber lain: that's one advantage of AP not specifying a specific URI scheme
# fr33domlover Idk maybe tag federation could become possible that way?
# lain one of the few times where not specifying things is good :)
# fr33domlover (currently tags are being done using a centralized location both in pump.io (tags.pub) and diaspora (they use some relay servers iirc for this?)
# fr33domlover whih is not the most amazing solution
# cwebber lain: and indeed, not everyone agrees it's good
# cwebber lots of people think we should have said https and https only
# cwebber but chances are, if that's really the direction the network will take, it'll be because implementations only speak https anyway
# fr33domlover That's what people clearly do best: Disagree
# Emelia (for any system I'd be designing, I'd be mandating https, honestly there's no reason not to with the ease of getting a certificate now through letsencrypt)
# cwebber well obviously one shouldn't target http :)
# cwebber there are other uri schemes, though
# Emelia well, SSL, at minimum :P
# cwebber in the sense that everything must be delivered over a secure channel, yes :)
# cwebber however, and I think the Switter CloudFlare stuff convinced me even more so of this, it's important to have ways to get some content over stuff like content addressed storage
# cwebber and with either URNs or magnet URIs, you might specify the content and get it over a secure mechanism, but might not specify exactly what mechanism that is
# cwebber could be a DHT... could be a sneakernet!
# dansup AP over cjdns would work, I used to run a statusnet instance on hyperboria
# lain hyperboria is just normal ipv6 though :)
cdchapman joined the channel
# dansup yeah, could use gateways like ipfs does
# dansup kinda defeats the security of cjdns tho
# lain there's a script for auto-setup of an onion pleroma instance, freedombone supports it too, now
# lain either both clearnet and onion or onion-only
# lain pretty interesting stuff all around
# cwebber yes, tor .onion services are a clever and surprising way to get a lot of stuff that's "p2p-ish" without having to dramatically rewrite code :)
# cwebber I, too, am excited.
# cwebber however I think tor .onion addresses really won't work until we start building petnames support into clients
# cwebber especially when v2 .onion addresses come out
# lain yeah, the names don't look too nice :)
# dansup lain: interesting, how do you handle clearnet and onion url generation?
# lain i don't really know how it works
vasilakisfil joined the channel
# dansup lain: do you store local status urls in the db or does the app generate them based on the url env var or config? I know gnu social stores local urls, makes changing domains a bit harder
# lain we store them, too.
# dansup hmm, I was going to use hashids but I will probably just stick with the id of the status. Will make pagination easier I guess. https://i.dansup.xyz/0Y0Z231l1r2c
cdchapman joined the channel
# cwebber Gargron: nightpool: commented, at long last.
Guest84_, cdchapman, fr33domlover and mahmudov joined the channel