Feature/profile picture upload

[muskanpaswan]

No description provided.

[enok1111]

Hi @julienmalard. As you may have seen in some earlier commits, I removed the Constellation plugin and moved the initialization of Constellation client into the Orbiter constructor. Also, any reference to the Constellation client via the Orbiter instance should now use orbiter.constellation, that’s the structure I want to maintain going forward.
What do you think? If there is not problem. Can you please add optsConstellation in the Orbiter client constructor?

[Zorlin]

Please make sure you provide a detailed list of the changes your PR is introducing.

[julienmalard]

Hi @julienmalard. As you may have seen in some earlier commits, I removed the Constellation plugin and moved the initialization of Constellation client into the Orbiter constructor. Also, any reference to the Constellation client via the Orbiter instance should now use orbiter.constellation, that’s the structure I want to maintain going forward. What do you think? If there is not problem. Can you please add optsConstellation in the Orbiter client constructor?

Hi @benya7 I agree that using orbiter.constellation is better for accessing Constellation. I think however that Orbiter should be intialised with an instance of Constellation and not of optsConstellation, for a few reasons. Firstly this seems to be the convention (e.g., helia is initialised with libp2p, orbitdb is initialised with helia, and Constellation with orbitdb). In addition, this allows for more configuration, since this allows end-users to modify, if needed, the Constellation instance that is used. For instance, using new or custom transports in libp2p will require passing an instantiated libp2p instance to the Constellation constructor and then passing this on the the Orbiter initialiser, which is not as easily done with optsConstellation.
Could we keep the constructor as it was before? I do think that having only an orbiter plugin is fine, though (and we could initialise Constellation there, without a separate plugin).

[julienmalard]

Please make sure you provide a detailed list of the changes your PR is introducing.

• New options for editing one's profile (name changes work; profile picture is locally mocked for now but @muskanpaswan is working on that at the moment).
• Option to see which other users are online, as well as the last time our peer connected to them
• Default off switch for the point above.

[enok1111]

Hi @julienmalard. As you may have seen in some earlier commits, I removed the Constellation plugin and moved the initialization of Constellation client into the Orbiter constructor. Also, any reference to the Constellation client via the Orbiter instance should now use orbiter.constellation, that’s the structure I want to maintain going forward. What do you think? If there is not problem. Can you please add optsConstellation in the Orbiter client constructor?

Hi @benya7 I agree that using orbiter.constellation is better for accessing Constellation. I think however that Orbiter should be intialised with an instance of Constellation and not of optsConstellation, for a few reasons. Firstly this seems to be the convention (e.g., helia is initialised with libp2p, orbitdb is initialised with helia, and Constellation with orbitdb). In addition, this allows for more configuration, since this allows end-users to modify, if needed, the Constellation instance that is used. For instance, using new or custom transports in libp2p will require passing an instantiated libp2p instance to the Constellation constructor and then passing this on the the Orbiter initialiser, which is not as easily done with optsConstellation. Could we keep the constructor as it was before? I do think that having only an orbiter plugin is fine, though (and we could initialise Constellation there, without a separate plugin).

Thanks for the detailed explanation! Fair enough, let's keep the Orbiter constructor as it was before and initialise Constellation in the Orbiter plugin.

[Zorlin]

This will need to be reworked potentially.

Can someone please rebase on zorlin/peerbit-rewrite?

We'll merge it into the current flow.