I think a lot of artists are on https://mastodon.art

We can look at PeerTube for an example of a system that could be shaped into what I meant: when you look at a post (video) from peertube it links lists for likes, dislikes and shares (so basically upvotes, downvotes and boosts). These collections contain a totalItems property, but also list the peoples identities, but just imagine that it wouldn’t be there. When a user now likes the video, the creator of the video now sends out an Update acitivity to all subscribers. Now all subscribers can update the counts for likes, dislikes and shares. Only the “home instance” of the creator account knows about all votes, nobody else does, but nevertheless everybody else can now how many likes, dislikes and shares there are.

If we compare that to mastodon the first part of the statement is still true:

Only the “home instance” of the creator account knows about all votes, nobody else does

But that means that most instances just show 0 likes for most of the posts, because your instance only knows about likes originating from your instance…

As for your proposition: I couldn’t follow for some of it. However I think the risk of an actor abusing the creation of fake accounts and fake upvoters is not really a risk, that is what defederation is for… I would argue very much agains a lemmy specific protocol and some judge instances simply because then big instances would just have pretty much all the data again and it would definitely hurt interoperability because lemmy devs can then just take the easier route instead of implementing something according to AP spec

You cannot make votes completely private, one instance has to have the authority over which votes do exist. This instance should be the origin of a post or comment.

At the moment it works like this: you upvote a post, this upvote gets send to the author of said post AND the magazine and that magazine then broadcasts your upvote to all subscribers of said magazine.

I could imagine that the process looks a lot different: you upvote a post, this upvote gets send to the author of said post, the author of the post then sends an update to the magazine saying how many people have now upvoted their post and the magazine then broadcasts this info to every subscriber of the magazine.

With that you would of course have new limitations concerning moderation and maybe there are trust issues regarding the correct reporting of that upvote count, but only the author of the post (and their instance ofc) could technically know who upvoted their post. As in everything here this is a compromise and whether the gained privacy is worth the other limitations, I don’t know

Upvotes were already implemented when we did the fork. I guess we just never really thought about it. I honestly just have no opinion on whether upvotes should be public or not, so I don’t mind them being public, but I basically never check who upvoted my posts anyway, so might as well be removed… If people care about this I’d say it is just up for discussion…

I was actually the one removing it. I implemented the support for incoming downvotes and because I and others had concerns to keep showing remote users downvotes publicly we / I removed it.

There was and is not anymore

On mbin users can only see who upvoted a post. An admin can of course still go into the db and look there, but for users and mods there is no way to see who downvoted a post

The same can be said about gmail and it is the same kind of problem here. Yes lemmy.world is not a profit orient it giant, but it is still a problem when one actor has this power over a federated network. (the scale of the problem is of course a lot larger with gmail)

to interact with it from mbin you gotta pull in the original post, so copy the url from this one and put it in the search bar

Nope. That is not yet possible on mbin. Dislikes are received but not sended. I was holding back on implementing sending dislikes because that can’t be configured yet.

Give it a thumbs up so we know what to prioritize 😊

I’ve been focusing on the backend and federation stuff. But I promise that we will implement it this year :)

You cloud give mbin a try its developers are nice people :) Although there is only one app for it (interstellar)

We do not have a “project fund” or something like that. Some of us have donation sites to keep the servers running:

• mine: https://liberapay.com/BentiGorlich
• @[email protected] https://kbin.run/about
• @[email protected] https://melroy.org/thanks.html

My opinion: I do not want to get paid to develop mbin. That creates an obligation and turns it into something like a job. I already have a job and intend to keep it, additionally I don’t want to take the fun out of developing mbin. To commit to it full time or apply for grants or anything would currently be a big mistake I think

That was the message that was pushed out when @[email protected] started the fork, because a lot of people were not particularly fond of the way he did it. We were trash talked a lot in the first months and obviously (and sadly) that kinda stuck on a lot of people.

Mbin isn’t making any drastic changes

UI wise, that one is definitely true

and relying mostly on Kbin’s existing code as its base

This one most certainly not. We actually stopped porting kbin code a few months into the project, because it just was too much work and it was obvious that Ernest didn’t want us to. So everything which changed on mbin in the about 8-10 months since, was purely our own work. Of course the basis will always be kbin, but the form will most likely change

We’ve been keeping the UI mostly as is, because we all like it, however on the backend site of it a lot has changed. The biggest problems kbin had were compatibility wise (federation) and scaling wise. These were the points where we made huge changes. The federation compatibility has improved a lot (yes there is still a lot to do) and scaling/performance has also improved a ton.

The biggest UI changes we made are:

• new filter designs that work for threads as well as microblogs
• a subscription panel
• a usable instance wide modlog
• a cake day display
• and more stuff that I am forgetting at the moment (it’s been a while since I looked at kbin and I am mostly a backend dev)

The backend changes we improved are (imo) more impactful:

• (next release) direct messages are federating
• (next release) pins federate
• deleting users federate
• magazine descriptions are federating correctly
• mods federate
• reports federate
• incoming likes are working
• the “hot” sort actually makes sense with lemmy content because it also looks at upvotes and not just at boosts
• completely redone the hashtag system so it scales at all
• completely redone the background worker system so it scales better (partly next release)

And these are only the changes I could think of in 5 minutes. We likely changed a lot more things, which I just forgot.

Very cool

Zulip is pretty nice and I think it resembled discord the most out of the software I know

I like Nextcloud very much but this release (and the one before it) are really enterprise focused for which I don’t have a use case…

Yeah our user documentarion could need some inprovements. Though I doubt a lot of users would actually look at it…

The best way to link communuties is with the [email protected] which works on lemmy and Mbin, but not on kbin (I think)

On both you have to search for a magazine handle ([email protected]) if the magazine is not yet on the server. And not the magazine search but the regular search. It can of course be blocked by the instance, but most likely just nobody searched for it before. Most mbin instances are very small and even fedia only has like 4000 total users… Therefore not that many magazines/communities have been pulled in, yet…