#social 2018-07-11
2018-07-11 UTC
xmpp-social, vasilakisfil and timbl joined the channel
timbl, tantek, jaywink[m], cybrematrix, zauberstuhl[m], csarven[m], nightpool[m] and strk[m] joined the channel
# 
nightpool[m] ping
# nightpool[m] :D thanks loqi
# nightpool[m] cwebber2: can we get next meeting dates and times for the wiki page? https://www.w3.org/wiki/SocialCG still says 6/27 as "upcoming"
# nightpool[m] that's two weeks ago, today is 7/08
# nightpool[m] sorry, 7/11
# nightpool[m] It would imply that we're meeting either this week, but to my knowledge that's not true (because 6/27 was an off-week meeting to avoid the 4th)
# nightpool[m] s/either//
# nightpool[m] here here
timbl joined the channel
# nightpool[m] mastodon will convert videos into a Link, i don't think there's an provision for handling still frames
# nightpool[m] to the post
# nightpool[m] i don't believe so but i'd have to check
# nightpool[m] "Video and Image objects will create corresponding text status records with manually crafted text contents (title + URL)"
# nightpool[m] peertube sends thumbnails as `icon` but they're very tiny
# nightpool[m] and we don't currently use them
# nightpool[m] oh
# nightpool[m] that should work fine
# nightpool[m] mastodon will probably reject the video
# nightpool[m] because it's too long
# nightpool[m] i'm guessing it would just reject the single attachment
# nightpool[m] no that sounds like an attachment, not a Video
# nightpool[m] it's the difference between e.g. youtube, and tweets with videos attached
# nightpool[m] hmm. actually, we seem to be pretty reasonably relaxed with videos on the backend
# nightpool[m] the only main restriction is that they're webm or mp4, and smaller then 8MB
# nightpool[m] i thought there were also length limitations
# nightpool[m] but maybe it's just that people's phones take really high-quality videos 😄
# nightpool[m] uploaded an image: image.png (13KB) <https://matrix.cybre.space/_matrix/media/v1/download/cybre.space/qzSRGdZCvziYOzeBuxHoSTgn>
tuxether joined the channel
# tuxether is it possible to join this room via Matrix.org ?
# nightpool[m] yep!
# nightpool[m] https://matrix.cybre.space/#/room/#socialcg:cybre.space
# nightpool[m] there's also an xmpp bridge if i'm not mistaken
# tuxether awesome. thanks!
tuxether[m], timbl_, schmarty[m] and barnie joined the channel
# barnie given the use case "potential Customer (authenticated client) scans Vendor's (Organization actor) QR code to get the list of active Offers", what would be the best client-server interaction? Is this: "QR code == Vendor actor URI, GET vendor Organization, GET vendor Outbox collection filtered by 'active Offers' (querystring params)"?
# barnie or should the QR code be an Activity e.g. "QR code == Announce, GET Announce activity, 'actor'==vendor Organization, 'object'==Collection of active Offer activities"?
# barnie Or something completely different?
# nightpool[m] mmm
# nightpool[m] I would imagine that the most natural interaction is to have the QR code a URI for a Collection of Offers
# nightpool[m] that the vendor has control over.
# barnie Yes, I thought about that, but then I do not have information on the Vendor.
# nightpool[m] Each offer would have it's own vendor
# nightpool[m] if they're they same you can group them and display them the same as you would a single vendor
# nightpool[m] that's probably the more flexible way to do it
# nightpool[m] otherwise you can use attributedTo or similar on the Collection
# barnie They are all offers from the same vendor. Are you saying that the QR code should then return the Organization with an Offers collection? Ohh, the attributedTo on the Collection sounds good!
# barnie thanks a bunch, nightpool!
# nightpool[m] I'm saying like, you can process the collection and just say "oh, these all have the same vendor, let's use that one for display"
# nightpool[m] but yeah if attributedTo works better use that one!
# nightpool[m] no problem
saranix and timbl joined the channel
# 
jaywink[m] Gargron: cool stuff with the relay 👍 nice to see the concept on the AP side. interesting that you took the completely opposite way of nodes managing their subscriptions instead of the relays polling nodes for subscription changes. I guess it provides less need for node lists but something I'm thinking is that it will make decentralizing the relay network harder as subscribers will have to subscribe separately to all relays - and they might not know
# jaywink[m] all the relays
# jaywink[m] planning on implementing tag based subscribing as well, so that then it just delivers content that has certain tags? and I guess it deduplicates and delivers using sharedInbox?
# jaywink[m] but yeah nice to see that - this kind of thing will help especially new nodes to get into the network without hacks
tantek, timbl_ and timbl joined the channel
# puckipedia jaywink[m]: ... you mentioned sharedInbox. where does it even send the posts to
# puckipedia I thought mastodon didn't set the act- oh no
# jaywink[m] puckipedia: I assume it reads the following actors and stores their sharedInbox values and deduplicates them when delivering - or that was my question does it do that :)
# jaywink[m] if a server has thousands of followers delivering the same post 1000's of times to the same server might be problematic - but that is what sharedInbox is for. mastodon already uses by default, right?
# puckipedia jaywink[m]: so, the relay isn't meant to be subscribed to directly, I guess
# jaywink[m] how will you stop that? :)
# puckipedia awnyays I don't think sharedInbox works for this
# puckipedia because the audience that the messages are received for don't correspond with the audience it's sent to
# jaywink[m] the audience is always public afaict
# puckipedia yeah, but the relay isn't sending it to the followers of the user that authored the original post
# puckipedia it's sending to the followers of the relay
# jaywink[m] why can't you send it to the sharedInbox of the followers of the relay?
# puckipedia because then the activity should be addressed to "relay/followers" as well
# jaywink[m] I don't understand. the sender has no idea who is subscribing. what is the difference of sending to the inboxes of the followers of the relay versus sending to the sharedInboxes of the followers of the relay?
# jaywink[m] (sender = one who sends the post to the relay for relaying)
# puckipedia the difference is subtle and doesn't really work in most servers:
# puckipedia or, well, hm, how do I explain
# puckipedia right
# puckipedia the subtle bug is a different issue
# puckipedia but imagine: ~b follows ~a and ~relay. ~c posts a message to ~c/followers and ~relay. if ~relay sends this message to the sharedInbox of ~b, it'll never show up in ~b's inbox
# puckipedia but ~b did ask for the relay's messages
# puckipedia oh hmm, I wonder...
# jaywink[m] bug in mastodon? I'm not really talking about mastodon, but AP
# puckipedia no, but; this is expected behavior
# puckipedia sharedInbox just looks for the follower collections in the activity
# jaywink[m] if I implemented a server, I would show show all public messages to users on the server, if they happen to for example follow a tag, then it ends up in their stream
# jaywink[m] that is implementation detail :)
# jaywink[m] it all depends how you process a payload addressed to "public" arriving in the "sharedInbox" route
# puckipedia oh dangit this is badly specified
# jaywink[m] so yeah maybe it doesn't work that way for mastodon, which might be problematic for the relay if servers with 10000 users auto-follow all users to the relay
# puckipedia "Additionally, if an object is addressed to the Public special collection, a server MAY deliver that object to all known sharedInbox endpoints on the network."
# jaywink[m] but of course a server without sharedInbox could do that anyway - but then that is why we have sharedInbox, to help with delivery
# jaywink[m] which part of the spec is that, C2S or S2S?
# puckipedia s2s
# jaywink[m] "on the network" sounds a bit odd
# puckipedia I feel "to any arbitrary sharedInbox" is good enough
# jaywink[m] never noticed that before :| but otherwise that is exactly what I would do, except for me I don't have inboxes, I have streams which have their own logic not really related to AP :P
ma1uta and tantek joined the channel
# Gargron i'm not sure what you mean with this discussion tbh
# Gargron a server subscribes to the relay... once
# Gargron it's one inbox per server anyway
timbl joined the channel
# Gargron we're gonna add a system user to mastodon probably, in the future, which will then be used for signing such system-level requests
# Gargron so yes, no, it's absolutely not meant to be followed by end-users from the web UI
# jaywink[m] But anyone can, from a non-Mastodon server?
# nightpool[m] jaywink: if they want to, sure
# nightpool[m] but the posts won't be addressed to them, like puckipedia says.
# jaywink[m] Sure
# nightpool[m] so they won't show up in any inbox for a c2s api, this is solely so federated timelines are better for new instances.
# puckipedia <Gargron> we're gonna add a system user to mastodon probably, in the future, which will then be used for signing such system-level requests <- then give it the system user as actor? :P
# jaywink[m] I know. And c2s is not the concern
# nightpool[m] yeah
# nightpool[m] signed/attributedTo/actor, whatever
# puckipedia but yeah, kroeg is probably going to add a system user as wlel because Issues
# nightpool[m] does what I said about the inbox make sense puck? i think that answers your question about sharedInbox as well
# jaywink[m] I'm not talking about Mastodon. I assumed the relay would be more AP generic, not Mastodon specific
# nightpool[m] because nothing is every explicitly addressed to the relay.
# nightpool[m] the relay is ap generic
# nightpool[m] i'm answering on an ap generic level.
# jaywink[m] Not if it requires a system user. AP doesn't have a concept of server
# nightpool[m] it ..... doesn't require a system user
cwebber2 joined the channel
# jaywink[m] Sure, thus my point about delivery
# jaywink[m] It could be optimize via shared inbox
# jaywink[m] But bed now 👍
# nightpool[m] sure, that's a simple group_by optimization.
# nightpool[m] aaronpk: i honestly have never noticed
# nightpool[m] i guess ruby's openssl library just abstracts over it
# nightpool[m] puckipedia: the audience for the posts is the same no matter what.
# nightpool[m] it's not designed to show up in anyone's inbox
# puckipedia nightpool[m]: I am aware
# puckipedia however
# nightpool[m] it's designed to end up in a "the server is aware of this post but it's not addressed to any individual user on this server" no-mans-land
# puckipedia then don't use Follow?
# puckipedia hm
# puckipedia the spec is quite vague about this
# nightpool[m] i guess this is maybe an overloading of Follow but it seems pretty intuitive to me
# puckipedia ... sharedInbox should be fine as it contains the relay-style server escape hatch
# puckipedia nightpool[m]: the biggest issue with the overloading of Follow is implying that a specific Actor follows it
# puckipedia like, once you start sending messages to the relay the relay will start sending the public messages to you too
# nightpool[m] that sounds tricky
# nightpool[m] and annoying to troubleshoot
# Gargron you wouldn't know when to stop or start
# puckipedia Gargron: start whenever you get the first message, stop N days after the last message you get
# puckipedia like, it heavily implies you can't quite just "leech" from the relay servers
# Gargron why shouldn't you
# Gargron what if you only have 1 user on your server but the whole point is bootstrapping it with content
# Gargron in any case, i've yet to test what i got so far for its real-world usefulness
# puckipedia aaronpk: mmm. kroeg being in rust I'm slightly scared the same thing will happen there but it's really going to be a pain to test at this moment
# puckipedia aaronpk: kroeg-rs has no federation at all yet :<
# puckipedia Gargron: mm. Follow with a system actor, send to sharedInbox should be fine
# puckipedia probably not, probably just "oh looks the same"
# puckipedia aaronpk: the server has been built with federation in mind, infrastructure inspired by kroeg-c#, but this time like 10x faster
# nightpool[m] aaronpk: i'm assuming it's just because they're implemented in different languages
# puckipedia aaronpk: lemme see
# Gargron i am just using openssl, nothing special. i guess the key format originally came from magic-envolope
# puckipedia aaronpk: so I can't tell exactly what publicKeyPem should be...
# nightpool[m] https://tools.ietf.org/html/rfc7468#page-11
# puckipedia yeah that seems Reasonable Enough
# nightpool[m] PEM is a poorly-specified format and i know cwebber2 or someone else on here is annoyed that we're using it, but we're following the ld-signatures spec so there's not much we can do there.
# puckipedia I had to write custom code for this in C# :<
# puckipedia aaronpk: asdf
# technomancy is netstring like bencode?
# technomancy I dig it
# technomancy I've written a couple bencode implementations but it's nicer to see the structure visible
timbl joined the channel
# technomancy yeah, not having support for dictionaries is a bit of a bummer
# nightpool[m] aaronpk: people seem to be recommending phpseclib
# nightpool[m] frankly cwebber2 that looks very complicated to try and debug
# nightpool[m] even if the actual parsing code is simpler.
# nightpool[m] right but that gets into ascii protocols or binary w/ pretty printing protocols
# nightpool[m] true i guess
# nightpool[m] i've never had to dig into it deeper then "oh, starts with BEGIN PUBLIC KEY? looks good!"
# 
cwebber2 1D80D015CE87B0FB6A91A99CECC7D91D2D210B00E4B6E611DA51DB008F1DFE3FCAC6B27393FA781D45F9A15FC7B8785A3E86BA6592B2916CA22CF1E40FC85F85CACA590461154F58F3580B16398908EF32076F411299C28727C94D88B6A618F84DD73AEBED8270BCB6690928CB1BF250C35E1F6BF3B1B30D05BA246ECE8F69D9065DE26F4B3E0D814D70A9C27CB5B7B050C9090590D3A9EF83374F2643E5446FBD39DDB124DBF6DFDAA6D18E2560AD0CBFA11C959C9B7316BF19963A191967054E9FD97DC14D71082B30B1C90A46E8996682474C3BCB51BA0882958897B6DD35E41B5174D0
# cwebber2 (n #00DB1634E3D9DFAC97AE4734DAE968CCB15EE4815C82BDC254883DBB49FE1EF32268E82D4BBE0E35298C481C9DA1551642FAFF05AEC1A60712F1BB4BE7D25D7EFF7A4F89704A5A9AC232870CB9F2476C3B538A0E990A8825DEB73081D317001FB8A188600F2FEF5F5F570E857F3EE4355077A3C3918ED72723A56BA55C466D400658974D7DAD1F6B7B63C192B9C2704D98BBFF1C3BD5B8EF11A8ADC83ACB8FD8E9F1E792FDAD262415D13F2DEE55F330908CFDA9C3C8C32B64F7DD088457D34F445E2E2C83C6D680549DC9B6E6573B89496567204ED285E67A279F2F667080BA94
# cwebber2 nightpool[m]: http://theworld.com/~cme/examples.txt look at this doc, which has other things encoded too
# nightpool[m] being able to actually read the plaintext parts of the certificates would be nice
# nightpool[m] and also there's a huge range of security-critical code that already DOES the existing system
# nightpool[m] and getting people to move away from it seems impractical.
# nightpool[m] we should probably take this convo somewhere else
# nightpool[m] even if I do want to continue it
# nightpool[m] good luck!
# nightpool[m] meeting next wednesday?
# nightpool[m] thanks loqi
# nightpool[m] no idea
# nightpool[m] i don't think this is an issue for us?
# nightpool[m] the publicKeyPem stuff is all from https://w3c-dvcg.github.io/ld-signatures/
# nightpool[m] right, but we're using the key for both
# nightpool[m] and the LDS vocabulary for the key
# nightpool[m] yeah i'm trying to track it down now
# nightpool[m] yeah i think you should really ask them
# nightpool[m] it's possible that the RSA thing, as a certificate format, just straight up doesn't meet their definition of key here