#social 2019-01-22
2019-01-22 UTC
# 
fr33domlover Does anyone have insights about generating object/activity IDs?
# fr33domlover The AP spec seems to use UUIDv4 but there are shorter ways such as hashids
# fr33domlover Using hashids of length 6 is enough for a long time it seems, and 6 is much shorter than UUIDs
# fr33domlover I'm trying to compute the smallest number whose hashid is of length 6 lol and it's taking a lot of time, I guess it's a big number? ^_^
# fr33domlover Hmmm yeah it's roughly 3.7 million
# nightpool[m] seeing as they only need to be unique URIs, you can just generate them sequentially and it's fine
# nightpool[m] mastodon generated activity ids sequentially for a long time, and the only reason we stopped is for backfill reasons that we never actually ended up implementing
# fr33domlover nightpool[m], backfill? what do you mean?
# nightpool[m] we started using snowflake identifiers so that we could still sort by ID but generate activities at an arbitrary point in the past
# nightpool[m] and not mess up sorting
# nightpool[m] we eventually decided that we didn't want to generate activities in the past as part of migration though, so we gave up on that.
# fr33domlover nightpool[m], ah I see! The purpose of generating-in-the-past was for migration of accounts? Also what are snowflake IDs? I saw this term before but couldn't find a reference
# fr33domlover nightpool[m], btw hashids are shorter than the numbers they're generated from ^_^ so maybe I'll still use them, even if no intention to hide the number sequence
# nightpool[m] ¯_(ツ)_/¯
# nightpool[m] lots of ways you can go about things.
# fr33domlover nightpool[m], by snowflake ids do you mean the twitter thing?
# fr33domlover That's what web search finds :p
# nightpool[m] yep
# nightpool[m] well, i think twitter pioneered them
# nightpool[m] lots of places use them now though
# dansup fr33domlover: Pixelfed is going to start using hashids
# fr33domlover dansup, yay ^_^ what are your thoughts/considerations?
# fr33domlover I'm consiering to use hashids of length 6+
# dansup Its tricky because hashids are usually salted so if you change the salt, old hashids become invalid
# fr33domlover dansup, true! What about using plain sequential numbers?
# dansup you can hardcode the salt but then each hashid is easily enumerable
# fr33domlover I guess though just like you protect a privake crypto key, you can protect the salt
# fr33domlover From being lost
# dansup yeah true, "php artisan backup:run" will save it
# fr33domlover dansup, or generate salt randomly and keep the same way you'd keep some private key
# fr33domlover e.g. my app keeps a key for encrypting cookies
# dansup I could use the APP_KEY but I dont want to use that for hashids
# fr33domlover add another key that's all :)
# dansup yeah
xmpp-social, Chocobozzz and cwebber2 joined the channel
# fr33domlover Hi people! I'd like to implement a federated operation in which it's important to identify the person behind the user, e.g. if a server goes down and a new one launches with the same domain name, I need to know it's a new server with new users and can't trust the original `joe@myserver.net` is the same person as the new joe. I'm wondering how to best implement this. Ideas: (1) The server has a permanent
# fr33domlover signing key, if the key changes we assume it's a new server and don't trust the users are the same people (2) The server keeps a permanent private key for each user (3) Each user keeps the private key locally on their laptop, makes signature locally, and your server just delivers the signature to other servers
# fr33domlover I'd love to have any advice and thoughts you have about this
# JasonRobinson[m] fr33domlover (IRC): this is the advantage of using signatures. If the user changes -> all the signatures become invalid.
# fr33domlover JasonRobinson[m], yeah I want to use signatures. But HTTP signatures are irrelevant to this right now, because they are ephemeral and can the key can freely change with no harm done AFAIK?Or do servers generally assume a server change?
# fr33domlover I mean in social web generally there's no permission issue, like, you don't need edit permission to remotely edit stuff
# fr33domlover In my application it's needed so I need an extra key assumed to be permanent
# fr33domlover (AFAIK mastodon etc. simply re-download the actor if the sig verification fails, I treat the HTTP sig key as something that's valid just for the 30 seconds the HTTP sig is used)
# fr33domlover That way you don't have to personally sign stuff unless it's *required* to identify you
# fr33domlover Which isn't required generally in the social web, only for actions that will require permission in the future
# JasonRobinson[m] > <@irc_fr33domlover:cybre.space> JasonRobinson[m], yeah I want to use signatures. But HTTP signatures are irrelevant to this right now, because they are ephemeral and can the key can freely change with no harm done AFAIK?Or do servers generally assume a server change?
# JasonRobinson[m] Yeah http sigs are useless for this. I guess you would need LD sigs or salmon
# JasonRobinson[m] > <@irc_fr33domlover:cybre.space> Which isn't required generally in the social web, only for actions that will require permission in the future
# JasonRobinson[m] Diaspora (and afaict Zot, at least pre-AP?) protocol does sign all the payloads, so I wouldn't say "not used" in a general sense.
# fr33domlover I asked in more detail there :)
# fr33domlover JasonRobinson[m], well that means Diaspora and Zot have their users' content crypto linked by the same key, but generally it's not required on the fediverse AFAIK so can't rely on it
# fr33domlover (Unless we agree on it and HTTP sig keys become de-facto permanent)
# fr33domlover JasonRobinson[m], I'll look into salmon and LD sigs :) But I still wonder how to manage the keys exactly
# JasonRobinson[m] Isn't this a specific use case though? I doubt you'll be able to get everyone to do it
# fr33domlover Per server, per user, store on server, store on user's device, etc.
# fr33domlover JasonRobinson[m], I don't need other people to change their code at all :) It's a specific feature yes, a new one, so existing software not using it doesn't need to change anything
# fr33domlover JasonRobinson[m], I'm leaning towards using separate key, not the HTTP sig one, so that we don't have to agree on new stuff and make everyone change the code etc.
# fr33domlover Also crypto-wise it allows HTTP sig keys to remain ephemeral, assuming right now they are
# fr33domlover (I'm unsure, I'm digging in Mastodon source but I could easily miss this stuff)
# JasonRobinson[m] Are we talking about for example editing a remote issue?
# fr33domlover JasonRobinson[m], yes :)
# JasonRobinson[m] I still think it should go the exact way like editing a remote post -> you just send your edit request and the server respects it or not.
# JasonRobinson[m] I know we've discussed this before :)
# JasonRobinson[m] it's simple and it's tried and tested already in the social world
# fr33domlover JasonRobinson[m], yeah that's how I'm doing it but how does the server know it's the same Jason, not just same user but literally same person?
# fr33domlover JasonRobinson[m], otherwise it takes manual approval by the project members
# JasonRobinson[m] does it need to know that? AP pretty much relies on domain ownership...
# fr33domlover JasonRobinson[m], yeah but what if, say, you shut down a server, start a new one on the same domain, now user "joe" is a different person, not the "joe" from the old server
# JasonRobinson[m] I mean, what is the speciality of issue/PR management, for example, compared to social posts or blogs?
cwebber2 joined the channel
# fr33domlover JasonRobinson[m], in social posts you never edit remote stuff, so this hasn't been significant
# JasonRobinson[m] you do, for example in socialhome you send edits :)
# JasonRobinson[m] hubzilla also
# fr33domlover I'm wondering if de-facto everyone assumes different key means different person
# JasonRobinson[m] I can edit my post in hubzilla and vice versa
# fr33domlover JasonRobinson[m], yeah but edits to remote stuff? Are they applied automatically? How does the server know it's really you?
# fr33domlover Just based on HTTP sig being valid?
# fr33domlover (Even if the key is new?)
# JasonRobinson[m] well it checks the salmon signature. but in AP world it would use the normal HTTP sigs?
# JasonRobinson[m] if the key is new -> rejected, of course
# JasonRobinson[m] an edit is no different from new content in terms of checking the author
# JasonRobinson[m] it's just another activity
# fr33domlover JasonRobinson[m], hmmmm in that case, since Hubzilla federates with Mastodon, Pleroma etc. (am I right?) and the salmon key is the same as the HTTP sig key, I guess I can safely rely on the HTTP sig? ^_^ but then I'd like to write about it, hear platform dev feedback because we need to agree that new key implies different person, to avoid the risk someone doesn't assume different user and then bad stuff
# fr33domlover happens
# fr33domlover But if it's a different key, I'll use a different key too
# fr33domlover JasonRobinson[m], I read a blog post by pleroma dev kaniini in which they suggest blind key rotation - if that's really possible, it means we don't treat HTTP sig as identifying a person (and then it's best we agree on it and be sure SocialHome and Hubzilla use a separate key for salmon, not same one as for AP HTTP sig)
# JasonRobinson[m] Oh I don't know about Hubzilla and AP. But I don't see the principle different for validating a remote edit author between protocols, even if the signature system is different (salmon vs http sigs).
# JasonRobinson[m] but sorry, can't help you with your specifics :)
# fr33domlover JasonRobinson[m], HTTP sig is used for verifying the server approves the activity author identify, it can be used for 30 seconds and then the sig means nothing. But what I need is permanent identification like the PGP key you use to sign email, so I think we need to agree on whether HTTP sig keys identify the person or not
# fr33domlover JasonRobinson[m], kaniini suggests they don't, remote edits like you say mean the salmon key is assumed to be permanent,
# fr33domlover (and if it's same key as for AP, that makes AP HTTP sig key permament too i.e. identifies the person)
# fr33domlover JasonRobinson[m], thanks for all the feedback :) I hope to hear from people and see what they assume in their software
# JasonRobinson[m] > But what I need is permanent identification like the PGP key you use to sign email,
# JasonRobinson[m] I didn't understand though why do you need permanent identification?
# fr33domlover JasonRobinson[m], because if the HTTP sig key lasts for 30 seconds and then it means nothing to you, but you need to edit a remote document a year from now, we need to use a different key, one assumed to be permanent, otherwise the remote server can't tell it's still you (after those 30 seconds your key might have changed, like the blind key rotation kaniini suggests)
# fr33domlover JasonRobinson[m], and if we do assume the HTTP sig key is permanent, we need to make sure Mastodon, Pleroma, etc. devs like this idea
# fr33domlover Because if some do and some don't, that's potential for trouble
# JasonRobinson[m] Can't the remote server just check that it's you? I mean sure if you want to be sure the person hasn't created a new key or the domain been hijacked. But my question is, why is it important when it's not important in the social world? :)
# JasonRobinson[m] (it's possible I don't understand HTTP sigs enough and I'm missing something totally, sorry)
# fr33domlover JasonRobinson[m], well suppose you take the risk in the social world. But now imagine it's not post editing, it's merging a merge request, a matter of software integrity, you want to be *sure* it's the same person
# fr33domlover Maybe even critical enough to use user-generated private keys perhaps, to be 100% sure
# JasonRobinson[m] well, if you ask me, we shouldn't take that risk in the social world either ;)
# fr33domlover JasonRobinson[m], I agree! No reason to take the risk, it's easy to use separate keys, one permanent and one ephemeral
# fr33domlover So that non-edits posts don't unnecessarily carry your signature
# fr33domlover (Most stuff on the social fediverse is just posts and comments, not edits, they don't strictly need a permanent signature)
# fr33domlover (If Diaspora and Zot do provide them that's okay, but it should be possible not to, and that we all agree how)
# rialtate[m] sent a long message: rialtate[m]_2019-01-22_22:45:25.txt <https://matrix.cybre.space/_matrix/media/v1/download/cybre.space/pXAcqpWQpHCGqSkBrFNbaUrU>
# fr33domlover rialtate, that would work but its not federation, I'm seeking a solution that is transparent across servers, in which editing stuff locally and remotely looks the same to the user, using one account on one instance, its pretty much like described above about Hubzilla allowing remote edits etc.
# fr33domlover I know AP doesn't deal with this, that's okay, I'm seeking to define how to do it
# rialtate[m] fr33domlover: not mutually exclusive. The creation of a logical account solves the "who owns this identity" question. The actual editing of the objects occurs federated in tandem.
tantek joined the channel
# fr33domlover rialtate hmm I see but then its just implementation detail, its probably equivalent crypto-wise to one of the ideas I listed at https://socialhub.network/t/how-to-identify-the-person-behind-the-user-for-permission-purposes/270
# fr33domlover (Its like if I used a permanent server key)