Kalcifer

1. Show the timer for all the succeeding stacked pixels. Currently, you can only see the timer for the first pixel. I propose that the timer should be shown for all of the pixels in the stack, and not only the first.
2. A neat feature that r/place had was that you could click on a pixel and see the username of the account that placed it. I propose the same feature.
3. Consider creating a permanent canvas. It could be neat to see how a large, permanent canvas evolves over a long period of time.

If any of these suggestions require the modification of underlying code, and are not simple config changes, then I will suggest them upstream -- please let me know.

I'm not sure how practical/sustainable of a project this would be, but I feel that it could possibly be a useful project in the future if instances begin to purge old content due to storage constaints. The archiving service could store all the data using Object storage to archive it in read only. That way, at least people can still view old content in the possible scenario of rampant data loss across the Fediverse.

cross-posted from: https://lemmy.world/post/2452085

This is, of course, assuming that the instance is not hosted on the same network that the device your account is using is accessing it from.

cross-posted from: https://lemmy.world/post/2357075

It seems that self hosting, for oneself, a federated service, like Lemmy, would only serve to increase the traffic in the network, and not actually serve the purpose of load balancing between servers.

As far as I understand it, the way federation is supposed to work is that the servers cache all the content locally to then serve to the people that are registered to that server. In doing so, the servers only have to transmit a minimal amount of data between themselves which lowers the overhead for small servers -- this then means that a small server doesn't get overwhelmed by a ton of people requesting from it. Now, if, instead, you have everyone self hosting their own server, you go right back to having everyone sending a ton of requests to small servers, thereby overwhelming them. It seems that it's really only beneficial to the network if you have, say, hundreds of medium sized servers instead of, say, thousands, of very small servers. While there is the resilience factor, the overhead of the network would be rather overwhelming.

Perhaps one possibility of fixing this is to use some form of load balancer like IPFS to distribute the requests more evenly, but I am no where even remotely close to being knowledgeable enough in that to say anything definitively.

The most common answer I see is something along the lines of "it's the equivalent of liking a post on twitter". It seems that this is not the case, as the Mastodon devs seem rather adamant that they don't want "likes" in Mastodon. Perhaps it's a method of saving posts? Well, that doesn't make sense either, since there is already the ability to "Bookmark" a post to save it.

It really just seems like a "Favorite" is just a bookmark that tells the poster, and the public that you bookmarked the post. And even if this was the reasoning -- which is baffling enough as it is -- it wouldn't make sense since the whole point of boosting something is to tell the public that you like a post.

It really seems like the "Favorite" button has no actual unique purpose. In my honest opinion, Mastodon should just federate "Likes" like normal, and be done with it.

I have Nextcloud installed as a snap. I would like to back it up to a folder on a separate drive within the server. Nextcloud appears to have an official backup app, which I have installed on the Nextcloud instance.

Is it possible to connect a folder on a separate drive to Nextcloud running as a snap? What permissions should such a folder have?

Would I have to do anything on my end, or would everything be set up automatically when the update is pushed?

There's a growing concern that "bad-actors" are amassing troves of encrypted data, and storing it away for possible future decryption using quantum computers. Many services have put in efforts to make certain that their encryption algorithms are "quantum-safe", so as to protect against such attacks. Has Matrix done the same?

cross-posted from: https://lemmy.world/post/2077535

I'm not sure if it is entirely accurate to compare them in this way, as "Matrix" refers to simply the protocol, whereas "Signal" could refer to the applications, server, and protocol. That being said, is there any fundamental difference in how the Matrix ecosystem of federated servers, and independently developed applications compares to that of Signal that would make it less secure, overall, to use?

The most obvious security vulnerability that I can think of is that the person you are communicating with (or, conceivably, oneself, as well) is using an insecure/compromised application that may be leaking information. I would assume that the underlying encryption of the data is rather trustworthy, and the added censorship resistance of federating the servers is a big plus. However, I do wonder if there are any issues with extra metadata generation, or usage tracking that could be seen as an opsec vulnerability for an individual. Signal, somewhat famously, when subpoenaed to hand over data, can only hand over the date that the account was created, and the last time it was used. What would happen if the authorities go after a Matrix user? What information about that user would they be able to gather?

I'm not sure if it is entirely accurate to compare them in this way, as "Matrix" refers to simply the protocol, whereas "Signal" could refer to the applications, server, and protocol. That being said, is there any fundamental difference in how the Matrix ecosystem of federated servers, and independently developed applications compares to that of Signal that would make it less secure, overall, to use?

The most obvious security vulnerability that I can think of is that the person you are communicating with (or, conceivably, oneself, as well) is using an insecure/compromised application that may be leaking information. I would assume that the underlying encryption of the data is rather trustworthy, and the added censorship resistance of federating the servers is a big plus. However, I do wonder if there are any issues with extra metadata generation, or usage tracking that could be seen as an opsec vulnerability for an individual. Signal, somewhat famously, when subpoenaed to hand over data, can only hand over the date that the account was created, and the last time it was used. What would happen if the authorities go after a Matrix user? What information about that user would they be able to gather?