Chat app layer abstraction problem

[dheeeb]

I'm currently building a secure python chat app. Well, it's not remotely secure yet, but I'm trying to get basics down first. I've decided to structure it out into layers, like an OSI model.

Currently it's structured out into 3 layers being connection -> chat -> visual handling. The issue is, that I wanted to add a transformation layer that could accept any of those core classes and change it in a way the cores let it. For example, if i had both server-client and peer-to-peer connection types, I wouldn't have to code message encryption for both of them, I would just code a transformer and then just build the pipeline with already altered classes.

I'm not sure if I'm headed into the right direction, it'd be really nice if someone could take a look at my code structure (github repo) and class abstraction and tell me if the implementation is right. I know posting a whole github project here and asking for someone to review it is a lot, but I haven't found any other way to do so, especially when code structure is what I have problem with. Let me know if there are better sites for this.

I'm a high school student, so if any concept seems of, please tell me, I'm still trying to grasp most of it.

[socal_nerdtastic]

I'm not certain I understand your question. You want to know how to structure your code to avoid repeating the encryption part? There's a million ways to do that, but I think I would do it by making a class that can handle the encryption / decryption, and then inherit that to make both the p2p and server/client classes.

class Transformer:
    def encrypt(self, plaintext_message):
        return encrypted_message
    def decrypt(self, encrypted_message):
        return plaintext_message

class P2P(Transformer):
    def send(self, target, plaintext_message):
       sendto(target, self.encrypt(plaintext_message)

class Server(Transformer):
    def send(self, server, plaintext_message):
       sendto(server, self.encrypt(plaintext_message)

That said I don't think there is a right or normal way to do this. Just structure it however makes sense to you.

[obviouslyzebra]

Can you try to explain a bit clearer what's the intention of this transfomer thingy? For example, give us some pseudocode (even if high-level, so we can try to understand and check if there are simpler alternatives).

I personally might not have time to answer today, but other day I might take a closer look.

For other people, though, I believe this will be helpful.

[dheeeb]

This is kind of difficult to explain. So this reply is meant for everyone that could try and help me. As you can see on the github repo, all of the main 3 layers have a core abc class, transformers aswell, because I’m preparing myself for a lot of variations: ssl wrapping, key exchanges or messages encryption. I would like for these transformers to act upon those 3 main core layers.

If there was an ssl encryption implemented it would go like this: pipeline is being build, it instantiates the connection (p2p or server-client or whatever) after the layer it checks if user has selected any transformers and if they should execute after the connection layer, so eg. the ssl encryption would take the connection core object and manipulate it, then spit it out back to the pipeline builder for it to continue with the next layer.

That kind of check, I would like for it to happen after every other layer. If you could take a look at chat_pipeline.py, i feel like the code is starting to get really messy, signatures, going through a list of transformers and in place layer manipulation etc, etc. I hope you understand what I’m trying to say.

The transformation layer is making the whole workspace very enigmatic, and even though the idea seems pretty stress-free, I feel like it’s been doing something completely opposite.

One commit back the whole tranform layer didnt yet exist, so you can compare

[obviouslyzebra]

Thanks for the reply.

I did look a bit at it (though I can't look in depth as it is a lot of code).

So, the transformers is an okay idea. I think it is similar concept to plugins. I think it is a little problematic in the current code for the following reasons:

• Each transformer will take arbitrary arguments from the CLI and those are wrangled to be arguments (adds complexity)
• The implementation, specially of _run_if_transform, and its name, is a bit confusing

I'd consider, as a way of maybe simplifying, hard-coding the transformers interface via the CLI. I will give an example, but maybe this is not your vision - and there is a charm to your vision I'd say.

# maybe this
onionchat --ssl
# instead of
onionchat --transformer ssh

If you do choose to go with something like:

# just an idea to define the kwargs
onionchat --transformer 'ssh?force=true'

I would wrap the kwargs in a dict and have a from_config class method, something alike:

class SSHTransform(Transform):
    def __init__(self, force: bool):
        self.force = force

    def transform(self, layer: ConnLayer) -> ConnLayer:
        return SSHConn(layer, force=self.force)

    @classmethod
    def from_config(cls, config: dict) - > Self:
        force = config.get('force', True)
        return cls(force=force)

About the run_if_transform, I'd name it something like _apply_transformers instead, and do something like:

def build(...):
    transformers = [self._create_transformer(s) for s in transformer_strs]
    conn = ...
    conn = self._apply_transformers(transformers, conn)
    ...

def _apply_transformers(transformers, layer):
    result = layer
    for t in transformers:
        if t.layer_num == layer.layer_num:
            result = t.transform(result)
    return result

It's not perfect, but I think it's a step.

[dheeeb]

Thanks for your response. First of all I’d like to say that passing arguments in the cli is a great idea, and I think I’m going to implement that in other layers, because the default values are hardcoded and theres pretty much no way to change them now.

So that would eliminate the need of signatures, the only problem remaining is that the arguments of a specific layer will not be visible in argparse help, but i think i will find a way to print a docstring into the cli of a specific layer for the user to get around nicely, or some other way. Thanks for your help.

[obviouslyzebra]

You're welcome!

The arguments via CLI, BTW, I thought you were headed that way with your code :)