SoniEx2
/
paste
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Compare commits

merge into: SoniEx2:sctpub
Branches Tags
SoniEx2:sctpub
SoniEx2:shitlist
SoniEx2:mhttp
SoniEx2:tcpquic
...
pull from: SoniEx2:shitlist
Branches Tags
SoniEx2:shitlist
SoniEx2:mhttp
SoniEx2:sctpub
SoniEx2:tcpquic

No commits in common. "sctpub" and "shitlist" have entirely different histories.
sctpub ... shitlist

2 changed files with 18 additions and 170 deletions
Show Stats Expand all files Collapse all files

170
sctpub.md
View File

@ -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>

18
shitlist.md Normal file
View File

@ -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>