#social 2018-07-11

2018-07-11 UTC
xmpp-social, vasilakisfil and timbl joined the channel
#
cwebber2
oh shit you're right puckipedia
#
cwebber2
puckipedia: ah
#
cwebber2
the spec does say query parameters
#
cwebber2
looks like I did put them in my guile implementation
#
cwebber2
Gargron: I do think the mailing list style forwarder is a good idea
#
aaronpk
apparently something about my activitypub doesn't like Pleroma
#
aaronpk
any idea what might be different between Pleroma and Mastodon's inbox handling?
#
aaronpk
or follow mechanisms actually, i'm not sure i've actually tried delivering to a pleroma inbox yet
#
aaronpk
found it
#
aaronpk
apparently pleroma rejects "Accept: application/json" on profile URLs and only returns JSON with "Accept: application/activity+json"
#
aaronpk
great, and now it's failing to read the public key
#
aaronpk
Pleroma uses "BEGIN RSA PUBLIC KEY" but Mastodon uses "BEGIN PUBLIC KEY". is that significant?
#
Loqi
[Aaron Parecki] Thanks... found one issue and uncovered another. My site was failing to fetch your public key because Mastodon and Pleroma support slightly different content negotiation headers. Now it's failing because Pleroma public keys are PKCS#1 RSA, and Mastod...
timbl, tantek, jaywink[m], cybrematrix, zauberstuhl[m], csarven[m], nightpool[m] and strk[m] joined the channel
#
nightpool[m]
ping
#
Loqi
pong
#
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"
#
aaronpk
that's next week, not this week right?
#
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//
#
aaronpk
considering there's no agenda right now let's do next week
#
nightpool[m]
here here
#
aaronpk
i'd like to give an update on my experiences implementing activitypub
#
aaronpk
relatedly... let's see if I can correctly deliver a video to my followers
timbl joined the channel
#
aaronpk
hm, does it expect just a video file or a video and still frame?
#
aaronpk
I normally include a still photo as a fallback for mf2 consumers that don't understand video
#
nightpool[m]
mastodon will convert videos into a Link, i don't think there's an provision for handling still frames
#
aaronpk
into a link? like to the mp4 file directly?
#
aaronpk
or to the post?
#
nightpool[m]
to the post
#
aaronpk
hm then if I include a still frame as another attachment, will it show that as a preview as well?
#
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
#
aaronpk
oh interesting, this isn't at all what I was going to send
#
aaronpk
I was going to send a Note that has a Video in the attachments
#
nightpool[m]
oh
#
nightpool[m]
that should work fine
#
nightpool[m]
mastodon will probably reject the video
#
nightpool[m]
because it's too long
#
aaronpk
reject as in not show it at all?
#
nightpool[m]
i'm guessing it would just reject the single attachment
#
aaronpk
should I be sending videos like peertube instead? the thing is my videos usually won't have a name, and will have text content like a note instead
#
nightpool[m]
no that sounds like an attachment, not a Video
#
aaronpk
k, so it sounds like I should include the still frame as a fallback as well then, and maybe mastodon will at least show the still frame
#
nightpool[m]
it's the difference between e.g. youtube, and tweets with videos attached
#
aaronpk
kinda wish I had given myself a way to send this post to just one follower
#
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
#
aaronpk
interesting
#
aaronpk
this is 800kb mp4, so I guess it'll work?
#
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 😄
#
aaronpk
nice, searched for my post and it loaded up
#
aaronpk
says "GIF" in an overlay
#
aaronpk
totally works tho
tuxether joined the channel
#
tuxether
is it possible to join this room via Matrix.org ?
#
nightpool[m]
yep!
#
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 :)
#
puckipedia
jaywink[m]: so, it currently uses the as:inbox of the person that /signed/ the Follow request
#
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 👍
#
aaronpk
how are you all dealing with the difference between mastodon's and pleroma's public key format?
#
nightpool[m]
sure, that's a simple group_by optimization.
#
puckipedia
ok so: an actor (no matter system or not) Follows a relay. Any objects in the relay's inbox will be relayed to the followers of the relay. However, the audience that is on these posts now no longer conforms with what the sharedInbox expects. so it has to be /inbox
#
nightpool[m]
aaronpk: i honestly have never noticed
#
puckipedia
aaronpk: oh no. /me checks
#
nightpool[m]
i guess ruby's openssl library just abstracts over it
#
Loqi
[Aaron Parecki] Thanks... found one issue and uncovered another. My site was failing to fetch your public key because Mastodon and Pleroma support slightly different content negotiation headers. Now it's failing because Pleroma public keys are PKCS#1 RSA, and Mastod...
#
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
hm. you /could/ make most of the relay handling implicit
#
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
#
aaronpk
gosh I might have to switch to a different crypto library
#
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 :<
#
aaronpk
you should test federation sooner than later!
#
puckipedia
Gargron: mm. Follow with a system actor, send to sharedInbox should be fine
#
aaronpk
is there a particular reason that pleroma and mastodon chose different key formats?
#
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
#
aaronpk
can we lock down a specific format to avoid further drifting apart?
#
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...
#
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.
#
cwebber2
yeah I hate PEM
#
cwebber2
canonical s-expressions is a much better key structure
#
cwebber2
easy to implement in an afternoon
#
cwebber2
but... PEM is everywhere :\
#
puckipedia
tbh I'm glad there's a rust lib that can just /take/ PEM
#
puckipedia
I had to write custom code for this in C# :<
#
cwebber2
puckipedia: oof
#
cwebber2
yeah... one night I was like
#
cwebber2
"how hard could this be"
#
cwebber2
"it's just base64 encoded data, right?"
#
aaronpk
refuses to write code that does crypto from scratch
#
cwebber2
then I fell into the abyss of ASN.1 and etc
#
cwebber2
aaronpk: it's not really crypto even
#
aaronpk
but sadly php's openssl can't read the pleroma certs
#
cwebber2
it's just the encoding format
#
aaronpk
so now I am stuck
#
puckipedia
aaronpk: asdf
#
cwebber2
aaronpk: oof
#
cwebber2
btw, here's how easy canonical s-expressions (as used by SPKI/SDSI, which could have been what the world used instead of x.509, but didn't)
#
cwebber2
first of all, here's a netstring
#
cwebber2
5:hello
#
cwebber2
we can put them next to each other
#
cwebber2
5:hello5:world
#
cwebber2
well, so why not wrap them in a list
#
cwebber2
(5:hello5:world)
#
cwebber2
if we want to pretty print that we can
#
cwebber2
(hello world)
#
cwebber2
but the netstring'ish one is already the canonical form
#
cwebber2
works great
#
cwebber2
so, an rsa key would look like
#
technomancy
is netstring like bencode?
#
cwebber2
(public-key
#
cwebber2
(n n-mpi)
#
cwebber2
(e e-mpi)))
#
cwebber2
(10:public-key(3:rsa(1:n128:baohbsoiahsdboihogaisdh...)(1:e3:100)))
#
cwebber2
easy to parse
#
cwebber2
technomancy: very similar!
#
cwebber2
it's more the opposite
#
cwebber2
oh wait
#
cwebber2
yes, bendcode *uses* netstrings
#
cwebber2
but bencode is also very similar to csexps
#
cwebber2
canonical s-exps (csexps) came first
#
cwebber2
and imo are the world's nicest binary encoding scheme
#
technomancy
I dig it
#
technomancy
I've written a couple bencode implementations but it's nicer to see the structure visible
#
cwebber2
bencode does some things like define a structure for dictionaries/hashmaps, not just lists
#
cwebber2
canonical s-exps are a bit more open ended, just lists and atoms, that's it
#
cwebber2
usually the way structure is interpreted is that the first element of a list is interpreted as a data type tag
#
cwebber2
so you could do
#
cwebber2
(list (str cat) (str dog) (int 33))
timbl joined the channel
#
cwebber2
for '(cat dog 33)
#
technomancy
yeah, not having support for dictionaries is a bit of a bummer
#
cwebber2
(dict key1 val1 key2 val2)
#
cwebber2
def possible to represent, assuming you tag everything (including lists)
#
nightpool[m]
aaronpk: people seem to be recommending phpseclib
#
cwebber2
sorry everyone, blame nightpool[m] for setting off the "asn.1/pem sucks but look at this canonical s-exps thing" rant
#
cwebber2
obviously I am faultless ;)
#
nightpool[m]
frankly cwebber2 that looks very complicated to try and debug
#
nightpool[m]
even if the actual parsing code is simpler.
#
cwebber2
nightpool[m]: that's why there's an "advanced" display
#
cwebber2
so, I was showing the "transport" encoding
#
cwebber2
but there's an "advanced" encoding that's pretty-printed for humans
#
nightpool[m]
right but that gets into ascii protocols or binary w/ pretty printing protocols
#
cwebber2
nightpool[m]: well, it's certainly easier to read than PEM :)
#
cwebber2
which is completely opaque
#
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
here's the guix public signing key, for instance
#
cwebber2
(public-key
#
cwebber2
1D80D015CE87B0FB6A91A99CECC7D91D2D210B00E4B6E611DA51DB008F1DFE3FCAC6B27393FA781D45F9A15FC7B8785A3E86BA6592B2916CA22CF1E40FC85F85CACA590461154F58F3580B16398908EF32076F411299C28727C94D88B6A618F84DD73AEBED8270BCB6690928CB1BF250C35E1F6BF3B1B30D05BA246ECE8F69D9065DE26F4B3E0D814D70A9C27CB5B7B050C9090590D3A9EF83374F2643E5446FBD39DDB124DBF6DFDAA6D18E2560AD0CBFA11C959C9B7316BF19963A191967054E9FD97DC14D71082B30B1C90A46E8996682474C3BCB51BA0882958897B6DD35E41B5174D0
#
cwebber2
(n #00DB1634E3D9DFAC97AE4734DAE968CCB15EE4815C82BDC254883DBB49FE1EF32268E82D4BBE0E35298C481C9DA1551642FAFF05AEC1A60712F1BB4BE7D25D7EFF7A4F89704A5A9AC232870CB9F2476C3B538A0E990A8825DEB73081D317001FB8A188600F2FEF5F5F570E857F3EE4355077A3C3918ED72723A56BA55C466D400658974D7DAD1F6B7B63C192B9C2704D98BBFF1C3BD5B8EF11A8ADC83ACB8FD8E9F1E792FDAD262415D13F2DEE55F330908CFDA9C3C8C32B64F7DD088457D34F445E2E2C83C6D680549DC9B6E6573B89496567204ED285E67A279F2F667080BA94
#
cwebber2
A6BCDE97B89043E95BD1B70DE61DA666893B417196A180005466BC3A742FDF04E89B04460E3E6BC72E7F1B5FEA5B3092FEE551A3C447C12E104E65#)
#
cwebber2
(e #010001#))
#
cwebber2
the n is huge
#
cwebber2
and for human readability (this is the "advanced" format)
#
cwebber2
the n is in hex
#
cwebber2
but look
#
cwebber2
you can see where the n starts and ends
#
cwebber2
and where the e starts and ends
#
cwebber2
you can't tell that shit from PEM
#
cwebber2
and transforming this to the transport form is trivial
#
cwebber2
the transport form would be much shorter because you wouldn't need to hex encode the n component of the key
#
cwebber2
nightpool[m]: http://theworld.com/~cme/examples.txt look at this doc, which has other things encoded too
#
cwebber2
eg the certs and etc
#
cwebber2
imo it's not much harder to read than json, but:
#
cwebber2
a) it can encode binary data, which you can't do in json without bloating it through base64 encoding
#
cwebber2
b) very flexible, including being able to tag types that you can't easily in json
#
nightpool[m]
being able to actually read the plaintext parts of the certificates would be nice
#
cwebber2
the main problem with csexps is that two implementations need to agree on the meaning of the type tags
#
cwebber2
a friend and I started working on that but we haven't published the document yet
#
nightpool[m]
and also there's a huge range of security-critical code that already DOES the existing system
#
cwebber2
jokingly named "Spooky Cat" (SPKI is pronounced "spooky", and CAT stands for Canonical Atom Tags)
#
nightpool[m]
and getting people to move away from it seems impractical.
#
cwebber2
nightpool[m]: well yeah, this is one of those "the existing system has momentum, even if it sucks" things
#
cwebber2
nightpool[m]: you've heard me complain about certificate authorities and how there was a point in time where instead of certificate authorities, we nearly had a more decentralized system
#
cwebber2
that was coming from the SPKI / SDSI community
#
cwebber2
and indeed is what the lead of SSL / TLS (Christopher Allen) wanted to use
#
cwebber2
but, Netscape decided to ship with x.509 encoded CA certs, and the world moved that way instead.
#
cwebber2
that's my understanding of history, anyway.
#
nightpool[m]
we should probably take this convo somewhere else
#
nightpool[m]
even if I do want to continue it
#
cwebber2
sure... anyway I'm not sure I have more to say though :)
#
cwebber2
I should probably get back to my giant todo list anyhow
#
nightpool[m]
good luck!
#
cwebber2
thx! later
#
nightpool[m]
meeting next wednesday?
#
nightpool[m]
thanks loqi
#
Loqi
you're welcome, nightpool[m]
#
aaronpk
do I switch to this new php library? that sounds annoying
#
nightpool[m]
no idea
#
aaronpk
checks activitypub issues
#
Loqi
[aaronpk] #315 Specify public key format
#
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/
#
aaronpk
no this has nothing to do with LDS
#
aaronpk
I haven't touched LDS yet
#
aaronpk
this is for the HTTP signature
#
nightpool[m]
right, but we're using the key for both
#
nightpool[m]
and the LDS vocabulary for the key
#
aaronpk
so, you did make a decision about using the key outside of LDS
#
aaronpk
which means it is AP's responsibility to define then
#
aaronpk
also um, I don't see publicKeyPem mentioned anywhere in that LDS spec
#
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
#
aaronpk
in any case, I think the issue stands on activitypub, given that out of the relatively few implementations of activitypub, people are already doing different things