All of this user’s content is licensed under CC BY 4.0

  • 36 Posts
  • 68 Comments
Joined 1 year ago
cake
Cake day: June 22nd, 2023

help-circle



  • I’m not sure that there is much for actual server side support for cross posting just yet, but there is a way, at least on the web UI: if you click the two overlapping squares under you post title, it’ll open a new post with a link to the previous post and its content quoted underneath. It feels more like a work around for cross posting, but it does work.



  • Kalcifer@lemmy.worldtoAsklemmy@lemmy.ml*Permanently Deleted*
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    11 months ago

    TL;DR: There is no singular answer to your question, imo. Essentially just run the instance transparently, reliably, and actively, and it will be attractive to people.

    I’m not sure that there is one “best way” to grow an instance. An instance is essentially the fundamental governing framework for how the users interract with each other. You structure the rules around how you believe the users on your instance should interact, and those who agree with those rules will be drawn to them. Ideally, for sustainable growth in an instance, you also need reliable server infrastructure – the instance should be responsive, and have a reliable uptime. An instance’s admins must also actively moderate content. An instance with inactive moderators is not sustainable, and will quickly delve into hosting unwanted content on the instance which is undesirable for users.

























    1. Would you be able to ellaborate on the following

    matrix stores your profile info

    group membership

    ongoing conversation in plaintext

    As I am not exactly sure what you are referring to.

    1. In addition to metadata that matrix doesn’t encrypt

    I’m assuming that this statement is referring to what was said here:

    On the other hand, matrix stores your profile info, group membership, and ongoing conversation in plaintext, some of them replicated across homeservers


  • Hm, I have trouble trusting any information on that site for a number of reasons:

    1. They don’t seem to grasp the concept of a federated service, and how that plays a role with “Matrix”. As stated on this page, under “Riot/Element”:
    • There have been no code audit and an independent security analysis, and hence we must take Element’s word. No one can mark his own homework.
    • Matrix has had at least one embarrassing security breach, indicating that their infrastructure security is lacking.

    They seem to be referring to “Matrix”, and “Element” interchangeably which doesn’t make any logical sense as “Matrix” describes the underlying federation protocol, and “Element” one of many clients that exist. This line of thinking can also be seen in the comparison table; the column title is “Element/Riot”, and yet much of the data contained in the table is referring to things related to the protocol.

    1. Furthermore, it should also be noted that the quote in point #1 is complete misinformation, and blatantly false (it should also be noted that this information is repeated elswhere, including the comparison table). Firstly,

    There have been no code audit and an independent security analysis, and hence we must take Element’s word. No one can mark his own homework.

    Ignoring that they say “Element”, and, instead, assuming that they intended to say “Matrix”, from what I can see, there are at least two independent audits that have been done – their respective information can be found on the blog posts here, and here. and secondly,

    Matrix has had at least one embarrassing security breach, indicating that their infrastructure security is lacking.

    Ignoring the fact that this statement makes no logical sense since “Matrix” is a protocol, and therefore the idea of a “security” breach does not even apply, I’m going to instead assume that they are referring to the home-server “matrix.org”. The security breach I’m assuming that they are referring to is described in the blog post here:

    TL;DR: An attacker gained access to the servers hosting Matrix.org. The intruder had access to the production databases, potentially giving them access to unencrypted message data, password hashes and access tokens.

    I’m not entirely sure what the author was insinuating, since this is just something that affected the matrix.org homeserver and no one else, and has absolutely nothing to do with the security of the protocol on the whole. The only important thing with this is whether or not the retrived unencrypted data (ignoring the messages) has any affect of compromising the security of the user – this author, unfortunately, makes no effort to explore this idea, and just moves on.

    There are plenty of other discontinuties that can be picked apart from this person’s site, but these were the most immediately glaring.