Who’s Maximus? Don’t see any comments they made on the thread.
Haha, whoops. Maximus is another moderator and I thought they’d replied to this already.
To your fediverse posts however, it is intended for Mucklet to be a service allowing additional realms, though those would likely all have similar rules to this due to the location of hosting.
There are a few important points here that I think are being overlooked.
First and foremost, this policy change is not about what you actually play on Wolfery, be it character concept or scenes. This is a policy change with regards to what images you are allowed to upload as profile pictures, which are stored on Mucklet AB’s servers.
The service owner does not wish to take on the legal burden of hosting images that may be in a legal gray zone, especially as the content is hosted in a country with specific legislation that affects drawn art. This is a matter of following law. Whereas I can understand it makes it more difficult for certain character concepts to present the art they want, it is: 1) Not a prohibition from linking said art, just a ‘No thank you’ to hosting it on Mucklet’s servers. and 2) Not a policy change that affects the ability to play those characters, or play in scenes involving those characters.
Claiming this is a ban on the existence of young-looking characters is disingenuous. It isn’t. You may have art of your clothed young-looking character. You just can’t have suggestive or sexualized images of them on Wolfery’s servers.
3 Likes
If it’s a fediverse, it would be hosted in multiple locations on servers owned by furs other than Accipiter. Different domains, different machines, different countries.
Nodes, like IRC, Usenet, Mastadon, Telegram. Same concept.
I didn’t miss that at all. And I don’t think it’s disingenuous, what I said. What I play influences how I look. How I look will no longer be allowed, therefore it affects how I play.
Just host the images on Inkbunny like Green offered to do. That’ll take care of the issue.
Better for scalability, too, if you ask me. A server geared toward an image library will help the server load.
Allowing externally hosted content to be presented natively in the Mucklet client was discussed. But there are significant security concerns to this, and as I understand it, there’s no core security design in place to handle external content in the system.
It doesn’t mean it’s not possible, but as far as I know, there aren’t any plans for this at present. So don’t rule it out. But in the meantime, looking into alternative hosting for images that do not fit the policy change is the wisest option.
It’s entirely possible to code the Mucklet to where when it asks you the profile pic you want to use, it can point to another domain. They do that all the time in other places.
As for the security aspects, could you describe the issue?
The more likely issue will be when those domains no longer host the image, and the link breaks, but that’s hardly as bad. People just need to update their links. Heck, I’ll imagine most people will just link to existing f-list profile pics.
This reminds me of that one time else-MU I got suspended in an empty room over something entirely off-MUCK, only I was never actually told that, the server administration was so whimsical that their suspension room wasn’t clear it was for administrative suspensions, and one of the standard global exits worked in it, so I thought it was a soft form of idle-purge to move sleepers - since I’d been away for a year and a day - and carried on as usual. Cue a permaban for jailbreaking.
I know this is a bit tangential to the situation described, but it’s a good example of how direct messaging is usually the best policy vs. assumption.
This is kind of a privacy issue and also IB’s content delivery nodes wouldn’t allow it, my suggestion was more a manual “invite people to use some named alternatives and link to them”.
1 Like
I guess I’m trying to understand the security issue that arises, in the difference between displaying a picture in Mucklet, versus creating a text link whose URL opens up a new window and does the same thing.
I’m not the right person to go in depth about Mucklet specifically, that’s Accipiter’s domain. But off the top of the bat - IP logging, XSS attacks, MITM attacks, content spoofing, image library exploits…
Any data you do not have the ability to sanitize yourself before running through more code is a risk. Heck, given that we don’t even have the ability to control content size on external links, it could serve as a DDOS attack.
So yes, any changes that allow externally hosted content is not a matter of ‘just doing it’. It will first and foremost be a decision Accipiter needs to make, and then assess on how to do. In the meantime, what we need to do is comply with that policy, when it goes active.
1 Like
Inkbunny doesn’t allow embedding content into other websites. It’s not a hosting service, I don’t think many would appreciate that either. You’ll have to post links.
This reminds me of that one time I ended up suspended in an empty room over something entirely off-MUCK, only I was never actually told that , the server administration was so whimsical that their suspension room wasn’t clear it was for administrative suspensions, and one of the standard global exits worked in it, so I thought it was a soft form of idle-purge to move sleepers - since I’d been away for a year and a day - and carried on as usual. Cue a permaban for jailbreaking.
I… don’t think this is something that happened on Wolfery?
Host the server where Inkbunny is hosted and have it all under one domain then?
No, that’s why I said MUCK (not specifying which one, it isn’t relevant). Was an example of why quiet/non-specific actions can be bad. I’ve updated to clarify that I wasn’t talking about here.
No, that’s why I said MUCK (not specifying which one, it isn’t relevant).
coughs Whitefire vibes.
Oof. I guess I’m out of the conversation for the next three hours.