ShadowPouncer

Based on the comment, I think that what is wanted is a little different than what people are assuming.

First, it sounds like there is a desire to implement enough of the Mastodon API that various mobile Mastodon clients can connect to kbin.social and interact with that side of things. I have no idea how difficult this would be, but I suspect that it would be an interesting undertaking.

And second, unrelated, but it came up in the comments, and I think it would be an excellent idea, there is definitely a desire to implement a Mastodon-like way to export and import enough of your account information to easily migrate to another instance.

In my opinion, there needs to be an option that can both import and export a fully Mastodon compatible format, so that people can migrate from Mastodon to kbin, and can migrate back from kbin to Mastodon, at least for stuff where that makes sense.

At the same time, I am unsure if that format would be sufficient for everything required to migrate from one instance of kbin to another, or between kbin and lemmy.

And given that last point, it should come as no surprise that I think that if another format is needed, or even an extension to the existing format, that should really be coordinated with Lemmy, so that it is easier to move around the entire ecosystem.

The really really sad thing is, Reddit could have done a half decent job and made a fair bit of money, but they decided on stupidity instead.

Sure, it would have upset some people a bit, but... Not by anywhere close to the same degree.

Alright, we're sorry, but use of the API is going to have to start costing money for some kinds of uses.

First off, people that just want to scrape everything get the following access, and a much higher rate limit, but it's going to cost $x.

Moderator tools will always be free, but the API will require that the tool be associated with a moderator, and it will only permit access to subs that the user is a moderator for.

Community bots will generally be free, subject to the following restrictions.

And 3rd party clients will be charged a minimal amount, calculated to be roughly equal to what we are making from similar users on the official clients, to make up for lost ad revenue. Alternate options involving profit sharing may be viable, contact X for details.

By accepting the API agreement, you agree that use of the wrong class of API usage (for example, using the community bot or 3rd party client classes for data scraping) will be billed, retroactively, at $X * 10.

There. That's really not that hard. And people would have been much less upset at that, at least as long as the fees were actually as described, and not based on, say, how much they would like to make per user.

You'd probably want a free tier for 3rd party clients for users of specific account types. If the user is paying for Reddit Premium, maybe 3rd party clients don't get charged for API usage for that user account. Or if the user is a moderator for a given subreddit, API usage for that user on that subreddit is also free. With an API that the client can use to check the status of such things. If they were smart, they would also have a process for users with disabilities to have their accounts exempted from fees. That last one is hard, because you need a verification process, but it would get them a lot of good will.

Again... This shouldn't be hard. And it would have turned into a viable revenue stream!

Hell, flatly disclose that the 3rd party cost is 30% more than the average cost of using the standard client, to support the effort required to maintain the API. (Largely bullshit, but it makes those users more valuable than those that use the official client, while not being expensive enough to make it impossible for anyone to offer a 3rd party client at an even remotely sane cost.)

Yes, this would have very sadly been the end of free 3rd party clients... But I for one would have been... Okay with paying a small amount per month/year through the app store for a client that didn't suck.

Instead, Reddit decided that committing suicide was the better path forward.

The advice to always use a unique password per site is an excellent one.

The why is multifaceted, and some of them are moderately complex.

First off, not every site is going to be storing your password in a good a secure manner.

In an ideal world, every site on the planet would be hashing it with something like bcrypt with a fairly aggressive cost setting, and good salts.

And they would have a way to automatically rehash your password on login in the event that the password hashing settings change. (Almost everyone misses this one.)

In practice... It could be stored in plain text. It could be hashed with classic crypt(), or with md5 or sha1 with no salt. There are so many ways to get it wrong.

On the rehashing one, they could have picked something that was best practices at the time, you setup your account, and then two years later, best practices have changed, it turns out that there was a way to attack the previous way, so they change how they do it... And that's great for everyone who changes their password or sets up a new account after that change, but everyone who did it before that change? Well, those passwords are just sitting there hashed by the old method indefinitely.

Or someone could compromise the site, and grab every password everyone enters.

Or you could fall prey to a phishing attack, and type your login to what looks exactly like the site in question, but is infact a common typo of the real domain.

Again, there are a lot of ways for the password used on a site to get compromised. Many of those ways are entirely out of your control. It is standard practice for attackers to attempt to use that password and username / email on other services when this happens, just so that they can see what else they can get into.

Don't let that work.

I use + addresses for stuff.

Well, since I run my own mail server, I tend to use _ instead of + as the separator, simply because more places will consider it a valid address.

But it's amazing how useful it is to include the name of whoever you're giving the email address to in the email address. It lets you keep getting email for stuff like password recovery. And when an address is leaked, not only can you block that one, but you also get to know who leaked it.

Which is awesome for knowing which businesses to never use again.

Don't do this.

Just use a good, random, password generator with decent settings.

Varying away from that just to 'change the kind of password' is only going to reduce your security.

You want as many random bits of information as possible in the password. That's it.

If there are not already people running fediverse nodes that exist specifically to harvest potentially 'interesting' data, there will be.

You edited it? That's maybe interesting. You deleted it? Same deal, maybe interesting.

It looks like an email address? Definitely might be interesting. A phone number? Yep.

An address? Definitely could be interesting.

If you posted it, assume that it will always be available to the exact people that you don't want to see it.

When I was a teenager, well, there's a whole lot involved, but I basically didn't have any dental hygiene to speak of.

Who cared?

Well, I had more than one root canal by the time I was 20.

I'm a bit obsessive about it these days, but I have not needed any more root canals.

Take care of the teeth that you want to keep. Don't worry, if you don't, they'll go away.

The other big problem is that if it's big enough, it may be uncomfortable or down right painful for any partner.

Again, that's usually more of a girth than a length problem, though too much length can also result in pain. (Bumping into the cervix is, for most women, a rather painful experience.)