2 changed files with 18 additions and 170 deletions
--- a/sctpub.md
+++ b/sctpub.md
@ -1,170 +0,0 @@
 # 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: <https://cybre.space/@SoniEx2/101557574984189610>
--- a/shitlist.md
+++ b/shitlist.md
@ -0,0 +1,18 @@
 # Shitlist
 This is a list of my shitty ideas.
 I know they're shitty because nobody likes them.
 1. [IRC CWs](https://github.com/SoniEx2/CTCP-S/issues/13). Most hated thing I came up with.
 2. Preloading image descriptions from EXIF on Mastodon, and using them for custom emoji descriptions. Second most hated thing I came up with.
 3. Easy way to attach (multiple) tags to Mastodon posts based on custom (user-defined) presets.
 4. Mastodon post visibility that shows up on local timeline and on followers' home feeds, but not federated timeline or profile.
 5. Image editor with text editor interface.
 6. 3D programming language/environment.
 7. 3D desktop environment.
 8. Self-JITting JIT compiler.
 - - -
 You can boost and send comments on the associated ActivityPub post: <https://cybre.space/@SoniEx2/101805907004238330>