From adf669ed78ac99557c568513eb80a19a529f0e5c Mon Sep 17 00:00:00 2001 From: SoniEx2 Date: Fri, 8 Feb 2019 15:02:27 -0200 Subject: [PATCH] Talk a little about SCTPub and what I want/need --- sctpub.md | 159 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 159 insertions(+) diff --git a/sctpub.md b/sctpub.md index 0e2d046..cda7db1 100644 --- a/sctpub.md +++ b/sctpub.md @@ -1 +1,160 @@ # SCTPub + +Hi! So this is me trying to explain my plans with SCTPub (ActivityPub over SCTP). + +And remember: this is *my* idea, and I don't expect ppl will agree with it, and that's okay! I don't like TLS, doesn't mean I +refuse to use it. + +First, I'll talk about the choice of SCTP, and the choice of authentication and authorization mechanisms (which are actually +tightly coupled). + +## Why SCTP? + +SCTP is a little-known protocol, so the idea was to use it to make it more popular and to experiment with it. +SCTP is in theory capable of seamless proxying such that you can talk to the proxy at the same time as you talk to the target, +but nothing seems to use this feature. It would still be target-controlled and signed, but the proxy would have some control +over caching. For sensitive requests, they would go straight through to the server, without the proxy being able to read it. +This puts the proxy in a position of a semi-trusted middleware. Technically all routers on the internet need to be semi-trusted +middleware, as any of those routers can track you and target you (e.g. with ads) based on that - see: +[ALTER (LTE) attack](https://alter-attack.net/), which explains how a middleware can track (fingerprint) the pages you visit. + +Since we already need to somewhat trust the middleware to be able to do anything, we could use that semi-trust state to provide +more efficient caching. This can be used to a) reduce our server load and b) protect against DDoS attempts. So I guess at this +point it'd no longer be "pure" SCTP as it'd involve MITM relations between the server and the middleware, but that's okay. + +(I don't think this is the right place to go in-depth into this idea, tho, so I'll stop here. I like to believe mobile +operators would be happy with the possibility of downscaling their link sizes tho. This can even be used for private content +e.g. if you have a large chat group you just encrypt the large data (video, etc) and send the group a key, and the data gets +cached. Crypto is fun.) + +## Words about Authentication + +Registering on SCTPub would require an username and a password, as well as an email address and a display name (handle). The +username and password never get sent to the server, only the email address and the display name (handle). This means if the +server is MITMd or malicious or a phishing server is used, the user's identity (login information) is still protected. + +The login interface: + +``` ++-------------------------------------+ +| Login [x] | +| | +| Username: _____________ | +| Password: _____________ | +| Instance: _____________ | ++-------------------------------------+ +``` + +The registration interface: + +``` ++-------------------------------------+ +| Register [x] | +| | +| Username: _____________ | +| Password: _____________ | +| Instance: _____________ | +| Email: _____________ | +| Handle: _____________ | ++-------------------------------------+ +``` + +The authentication is done using a public key mechanism. The Ed25519 private key is generated: + + GO ASK ##crypto @ irc.freenode.net BECAUSE THEY INSIST THAT I'M NOT ALLOWED TO SPECIFY THIS STUFF WHEN TRYING TO MAKE A PORTABLE PROTOCOL + +The user should be able to change their username/password (aka login key). The user may have multiple login keys. + +Once authenticated, the key is to be replaced with a temporary, non-token-based (i.e. no cookies) session key. + +All messages encrypted or signed by the client must include the instance address. All messages received by the instance must +check the instance address. Nonces must also be used but w/e you probably know this better than me. Encryption vs signing +should be chosen as needed depending on the requirements (see also *Why SCTP?* above). + +## Words about Authorization + +Authorization should also be done with cryptography, and not OAuth. OAuth is awful. Please don't use OAuth. In fact, +authorization should be done with public key *encryption*, not even signing. The keys are revokable. The same +mechanism that allows zero-knowledge authentication can also be used for authorization, as it already provides all of this. + +Authorization doesn't need the session keys mechanism described above. In fact, that mechanism is a form of authorization. + +User agents may optionally authenticate themselves using an UA key. In other words, messages would be double-signed or +double-encrypted, once by the authorization key, once by the UA key. The authorization key should always be the "inner" key +while the UA key should always be the "outer" key. (e.g. UA signatures also sign the authorization signature.) + +This shouldn't be used by client-side UAs like mobile apps or web browsers. + +- - - + +Now that we have some of the security aspects out of the way, let's talk about the community aspects: moderation, interaction, +friendship, etc. + +## Communities + +One of the goals of SCTPub is to provide for *communities*, something we lost a long time ago with the downfall of forums. +Y'know, like phpBB and stuff. + +As such SCTPub *actively encourages* you to have different accounts on different intances, by not only making it easy to do +so (with the standard User Agent providing an easy way to sign up to other instances), but also through "dark patterns" +(sorry). The main dark pattern is that while ppl can boost your content to other instances' main feeds (separate from your +self-curated feed, more similar to the mastodon "Local Timeline" but including all interactions from local users - boosts, +etc), but you can't post on other instances like this. Ppl from other instances can choose to follow you, and your content +shows up to them, but it's not the same as being in the community. Think like Reddit, but each instance is a different sub. + +While there's no technical mechanism to encourage instances to have different rules, I do believe in different instances +having unique rules but still federating together. This would also support this "communities" model, and encourage multiple +accounts. + +## Moderation + +One of the things I miss a lot from the time we had forums is moderation. Back in the day, some forums, as elitist as it may +be, would require you to participate in a closed-off area before participating in the rest of the community. While I'm not +totally a fan of that idea, I do think a similar idea is warranted: participating locally before federating. This doesn't +(on its own) reduce spam on a local level, but it helps a lot on a federated level. The software *should* still allow +instances to opt into a pre-approval stage where you don't even interact with the locals, tho. + +Additionally, to register on other instances, some metadata would be sent across servers. Depending on the chain of trust +model of each instance, you'd either have to go through the moderator-approval stage on the other instance, or it'd trust you +because N other instances trust you, or because N instances on its trusted instances list trust you, or [...]. There's a lot +of flexibility here. + +Moderation requests (e.g. reports) should definitely federate, altho I haven't worked out all of the details with this. + +## Interactions + +This is a tricky one to explain, because I'm not trying to make another Twitter or Facebook. So bear with me for a second. + +Twitter and Facebook have an attention-based model. On Twitter and Facebook you're "supposed" to make posts that bring you +attention, like memes or shitposts or racist remarks. Reddit also encourages this to a slightly lesser extent. This is NOT +something I want, even if they're "technically" interactions. (besides, [there's an xkcd for that](https://xkcd.com/1475/)) + +Instead, we should look at forums. In forums, there's no pressure to have the most shared content. Instead there's pressure +to have the most talked about content. That's what I want when I talk about interactions. I want ppl to talk to me, not +just share my posts. Social isolation is awful, and altho liking and sharing do have their place as forms of non-verbal +communication (and I'm not proposing we remove them), they just aren't always enough. + +I want to bring back that cozy feel of forums, while taking it to the next level. The federated nature of the fediverse +allows for ppl to easily interact with eachother, which brings us one step closer to taking it to the next level. + +(I could go on about this all day, but I'm really starving and I'd like to finish this ASAP so I can go eat. it's getting +hard to stay focused now.) + +## Friendship + +Friendship is important, so just allowing interactions across instances while providing a cozy feel isn't enough. + +So there should be a way to keep up with your friends, and putting some emphasis on it. But I don't think it should be the +default. + +Both Facebook and Twitter have this thing where you can follow ppl. And then you follow too many ppl and it just goes too +fast. You can still follow ppl, and it should be encouraged, and there should be lists like in mastodon (or how reddit used to +have multireddits?) so you can organize things better, but the local timeline, which should be cozy, should be the default. + +(Big instances should be discouraged, while subject-specific/topical instances should be encouraged.) + +- - - + +Okay I'm too hungry to keep going. Cya another time tho. o/ + +Sorry that this was so long. I needed to write it down somewhere.