107

Suggestions for Canvas and future events! (programming.dev)

submitted 4 months ago by Ategon@programming.dev to c/canvas@toast.ooo

124 comments fedilink hide all child comments

Hey everyone! Thanks for participating in Canvas. I wanted to make a thread to collect together suggestions people have that can be worked on before the next Canvas.

Feel free to also throw in suggestions for future Events we can build and run for the fediverse.

Ill be collecting suggestions together and making issues for them in the repository for myself or some other contributors to work on (the projects open source so anyones free to contribute! https://git.sc07.company/sc07/canvas Feel free to reach out to me and I can help get you set up with the codebase)

you are viewing a single comment's thread
view the rest of the comments

[-] lvxferre@mander.xyz 2 points 4 months ago

Suggestions:

When getting rid of bots, undo their changes.
Assign the pixel timer based also on IP, not just account. That should discourage people who used multiple accounts just to have more pixels.
Don't let freshly created accounts to place pixels. They compound with both issues above.

[-] eatham@aussie.zone 9 points 4 months ago

IPs should never be used to moderate, they are shared across too many people. Often multiple neighborhoods will share an IP.

[-] lvxferre@mander.xyz 5 points 4 months ago

I do not like the idea of using IPs for that either, but since it's only for the timing instead of locking people out of the service, it's less of a concern.

And as db0 said IPs are far from optimal but they're the best thing that "we" [actually the devs] have available. If you have some alternative way to discourage simultaneous multi-accounting, by all means, suggest it here.

[-] BlueKey@kbin.run 4 points 4 months ago

Same with people who use VPN per default.

[-] db0@lemmy.dbzer0.com 3 points 4 months ago* (last edited 4 months ago)

That's the closest thing we have though. The alternative is just people using alts, and at that point might as well not have limits. There can be ways to add exceptions if needed.

[-] grant@toast.ooo 2 points 4 months ago

there's an issue to add support for undoing pixels with bans, but that would mainly get used in very bad circumstances and wouldn't be the default

as others have mentioned, there's not going to be anything that automatically does actions against IPs, instead opting for a flag that moderations can look into further

i've also mentioned somewhere else in the thread, but i wouldn't want to punish new accounts as, especially this year, it brings new people to the Fediverse and i don't want to hamper the growth of that :) (it also isn't very possible to get a reliable creation date of new accounts because of how the fediverse is designed)

[-] lvxferre@mander.xyz 2 points 4 months ago

OK! At least the other batch of suggestions was more useful :) Those are fair points.

[-] possiblylinux127@lemmy.zip 2 points 4 months ago* (last edited 4 months ago)

If you undo the changes done by a bot it could cause chaos. It is better to let users know it needs to be fixed.

Also you could do some sort of proof of work to make it unfeasible to have a bunch of alts.

[-] lvxferre@mander.xyz 1 points 4 months ago

If you undo the changes dome by a bot it could cause chaos. It is better to let users know it needs to be fixed.

It could cause chaos if done poorly, indeed. But I think that there are ways to minimise this chaos.

One of them would be that reverted pixels are marked as "reverted by the admins", and that appears in an overlay similar to the heatmap.

Also you could do some sort of proof of work to make it unfeasible to have a bunch of alts.

Like in cryptography? I like this idea. Perhaps it could be used when there's a reasonable possibility that two accounts are from the same user; for example same IP, or same username but different instance, etc.

[-] possiblylinux127@lemmy.zip 2 points 4 months ago

The only problem with proof of work (pow) is that it won't perform the same across devices and will kill battery life. The difficulty of the proof would need to be calculated on page load which could open it up to spoofing a different device.