# 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. This metadata would be composed of the originating instance, the target instance, and it would be signed by the user's login key. This metadata is then used to build a chain of trust (web of trust?) of sorts. Also, because you have to sign it, you actually have full control over which instances/accounts know about your other accounts. 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. This chain of trust can also be stored, and retrieved at login time, allowing for smooth login across many instances (see Communities above). If one of your instances is down, that's no big deal - just login on another! I don't have many accounts across the fediverse because of how hard it is to manage them, but this alone would make it a lot easier. 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 flame wars. 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. You can boost and send comments on the associated ActivityPub post: