Add optional password confirmation to add scroll to click sites

[ACDragonMaster]

So, my scroll is set to NOT accept help from others.  Sometimes I have a dragon that I'm deliberately allowing to get to low time to get offers on a trade, after all, and because it's in a trade I can't fog it.  And yet, I've repeatedly wound up with people adding my dragons to click sites anyway recently, often when I'm not online, to the point where I was unable to accept a trade offer because the hatchling grew up.  This is unacceptable, and I feel there's a very easy fix: have an option that can be enabled on user accounts to require password authentication when adding a scroll/dragons to a click site.

 

Yes, I realize that this would require some overhauling to the API, but I know this sort of thing can be done (the usual method would be that the other site--a click site in this case--passes you back to dragcave.net where you're required to enter your password similar to doing so for BSAs, then dragcave passes this info back to the click site which now allows you to add your dragons).  And frankly, I'm getting very, very annoyed at losing trades or having to search through every click site I know of until I find the one my dragons have been added to against site rules and remove them.  And this absolutely IS a significant problem, I had eggs I picked up late last night on my scroll, and when I came back to check when I got home tonight?  They already had views from being added to a click site.

 

This has to stop, and clearly simply putting a warning on the dragon's page is not enough.  Having an opt-in possibility of requiring authentication would perfectly address the issue.  People who don't want their scrolls messed with can opt in, and it could be automatically disabled if someone chooses the option to allow help from others.  Nobody's forced into it, and nobody's forced to go trawling through half a dozen click sites to find where someone added their dragons without permission to remove them.

[Shadowdrake]

For what it's worth you can prevent your scroll being added to clicksites by hiding it in account settings. That takes care of most problems like these.

[KageSora]

Yeah, this is a real issue and something needs to be done about it.  It's been suggested to prevent things in trades from gaining views (or at least have the option to block them from getting views), which I think might work a little better--if you need to update your stuff in a bunch of sites repeatedly it would get real tedious real fast having to re-enter your password every single time, but also.  I really, really hate trades getting spoiled because somebody "helpful" shoved it in an ER.  (Or, well, maybe they're not trying to be helpful--maybe they're being spiteful because you rejected whatever they offered so they figure if they force your thing to mature then you don't get to trade it with anybody else, either.  People might do that with eggs, too--try and viewbomb it to death in revenge for not having their offer accepted...  Obviously you can't prove anybody has done that, but I do wonder sometimes...)

 

Whatever is done, it needs to be something because it's just plain frustrating running into this kind of thing.  😕

[Shizuku-chan]

What you've described have already been implemented in one click site, DragHatch. Unless all the click sites implement an API login like what they did, randoms would be able to add your dragons on whatever click site(s) that uses an unsecure method (solely scroll name or dragon code) to access your scroll, which is basically most of the click sites right now. I'm not sure if there's any push on the click sites' end to fast track this but perhaps we can all pressure those click site owners to do so.

 

Personally I've resorted to just hiding my scroll completely and only using DragHatch as my main hatchery because they're the only click site that offers a secure login and I'm only opening my scroll up temporarily to ER <4 days eggs/hatchlings on other click sites.

Edited December 31, 2022 by Shizuku-chan

[Fuzzbucket]

Even if TJ were able easily to prevent people adding to click sites, there are so many other ways to view bomb things. I too use draghatch as my main site, and hide my scroll when necessary, but making all click sites ask for verification can never stop viewbombing altogether,.

I do think preventing things in two-way trade from gaining views would help.

[ACDragonMaster]

I think a lot of people are misunderstanding what I'm suggesting.  I'm not saying that all click sites should always require a password verification.  I'm saying that it should be possible to tweak the API such that IF you toggle the option in your account to 'on', then and only then will the API force a verification.

 

So basically, if you're doing some specialized trading, or worried about view bombing, you can temporarily turn on the feature and still add your scroll to various sites as you please, while preventing anyone else from doing so.  All while leaving your scroll visible to people if you want your friends to still be able to see it.  And if you don't want the hassle?  Turn it off!

 

Simple, really.

 

EDIT: I should also note that what I'm suggesting would be ENTIRELY enforced by the actual dragcave site itself.  You turn the option on, and ALL click sites that use the API would be forced to obey.  It's nice that draghatch has an optional verification process, but that won't stop someone from maliciously using your scroll name or dragon IDs to add them to other click sites that lack that protection.  What I'm proposing would be something that click sites wouldn't be able to opt in or out of, if you have it active on your scroll, then absolutely none of them that are using the authorized API would be able to add your dragons without the verification.  Period.  It would be a much more effective protection against malicious actors, and would mean that users wouldn't have to resort to things like hiding their scrolls out of paranoia.  This is a game, you should be able to share your scroll if you want to without having to be concerned about someone viewbombing your dragons.

Edited December 31, 2022 by ACDragonMaster

[KageSora]

The problem is that folks like me still actively hunt WHILE doing the trading, and hunt the AP at that.  Which means enabling it for 4 days while something is sitting in trade limbo means extra hassle every single time you want to update your scroll on a site unless you just don't hunt for things while you have the trade going.

 

Having to pick between continuing to hunt and hatch things with minimal hassle or being able to trade safely doesn't sound terribly appealing to me, which is why I'd prefer the idea that things have an option to just stop getting views in trades rather than the only way to protect my trades being enter my password 50 times as I put things in and pull them out of click sites while there's a trade I'm protecting up.

[ACDragonMaster]

9 minutes ago, KageSora said:

The problem is that folks like me still actively hunt WHILE doing the trading, and hunt the AP at that.  Which means enabling it for 4 days while something is sitting in trade limbo means extra hassle every single time you want to update your scroll on a site unless you just don't hunt for things while you have the trade going.

 

Having to pick between continuing to hunt and hatch things with minimal hassle or being able to trade safely doesn't sound terribly appealing to me, which is why I'd prefer the idea that things have an option to just stop getting views in trades rather than the only way to protect my trades being enter my password 50 times as I put things in and pull them out of click sites while there's a trade I'm protecting up.

 

I mean, to be frank, why not both?  I don't see why this has to be a mutually-exclusive thing at all, and I don't know why people are so quick to take suggestions as inherently implying "if x gets implemented then y can't possibly be" when that's never stated.  This attitude in fact is very counterproductive to ANY suggestions being enacted as it creates division instead of mutual support.

 

But basically, these are different solutions that address different particular needs.  One would benefit all users all the time (preventing views while in trade) while the other would be situational and a boon to users who have concerns or have been recently attacked (an option to require authentication).  I see no reason why both cannot be implemented, short of, of course, TJ simply not wishing to use one or the other for some reason.

[GhostMouse]

I support this. Having to put in my password a few times while I have an active trade (or all the time) seems like such a little thing to ensure the safety of all my growing things. I use a password manager so it just takes a couple of clicks for me. But even typing it in doesn't seem like a huge burden to me? Plus it's optional, so no one is forced to use it if it doesn't work for them.

 

I also like the idea of (optionally) protecting things in trades from views, and I don't feel like these are mutually exclusive (or even opposing) ideas. But I don't want to take this thread off topic.

[KageSora]

3 hours ago, ACDragonMaster said:

I mean, to be frank, why not both?  I don't see why this has to be a mutually-exclusive thing at all, and I don't know why people are so quick to take suggestions as inherently implying "if x gets implemented then y can't possibly be" when that's never stated.  This attitude in fact is very counterproductive to ANY suggestions being enacted as it creates division instead of mutual support.

 

But basically, these are different solutions that address different particular needs.  One would benefit all users all the time (preventing views while in trade) while the other would be situational and a boon to users who have concerns or have been recently attacked (an option to require authentication).  I see no reason why both cannot be implemented, short of, of course, TJ simply not wishing to use one or the other for some reason.

 

Mostly it's because the game is not maintained by an army of coders who can easily do multiple solutions to the same problem.  It's inefficient for TJ to spend his time working on multiple solutions to the same problem instead of solving multiple problems or adding new features.  It's entirely up to TJ how he wants to proceed with things, of course--that's one reason giving multiple suggestions is important because if he does want to address something having multiple options that users already support may be easier than trying to figure something out from scratch.  But there's no guarantee that TJ would implement any solution to a given issue much less multiple solutions.  So trying to count on "well, we can have more than one" when there's all likelihood that we will get none or only one is not terribly useful when a proposed solution introduces it's own flaws.

 

This proposed solution addresses the problem of viewbombing and trade spoiling--but it also creates another issue in the flaw of "if you are actively hunting over and over and repeatedly updating your scroll, then your playstyle means you either have to forfeit the added protection on your trades or you have to enter your password 50 times in 20 minutes which is annoying as heck".  Part of what this entire subforum is for is to discuss suggestions and refine them to work around flaws in them.  This isn't always possible because sometimes the core of a suggestion is simply 100% at-odds with the flaws it will create and there's no real middle ground.  Sometimes it is possible to discuss possible flaws and drawbacks and to work around them to a modified idea that addresses them well.  You never know that until you actually discuss the matter.

 

This specific idea does not seem to have a means of mitigating the problem it would introduce, which means choosing between being significantly more inconvenienced or abandoning a current playstyle if you want the added protection or choosing to leave yourself vulnerable and continuing to fall victim to the issue this seeks to address.  Therefore, while I would not be opposed if this were introduced in tandem with other solutions, I cannot support this idea over something like optional halting of views in trades should TJ only wish to pick one idea--which would solve both the issue of trades being spoiled and would not introduce the issue of "choosing between your current playstyle and trade protection".

[ACDragonMaster]

5 minutes ago, KageSora said:

 

Mostly it's because the game is not maintained by an army of coders who can easily do multiple solutions to the same problem.  It's inefficient for TJ to spend his time working on multiple solutions to the same problem instead of solving multiple problems or adding new features.  It's entirely up to TJ how he wants to proceed with things, of course--that's one reason giving multiple suggestions is important because if he does want to address something having multiple options that users already support may be easier than trying to figure something out from scratch.  But there's no guarantee that TJ would implement any solution to a given issue much less multiple solutions.  So trying to count on "well, we can have more than one" when there's all likelihood that we will get none or only one is not terribly useful when a proposed solution introduces it's own flaws.

 

This proposed solution addresses the problem of viewbombing and trade spoiling--but it also creates another issue in the flaw of "if you are actively hunting over and over and repeatedly updating your scroll, then your playstyle means you either have to forfeit the added protection on your trades or you have to enter your password 50 times in 20 minutes which is annoying as heck".  Part of what this entire subforum is for is to discuss suggestions and refine them to work around flaws in them.  This isn't always possible because sometimes the core of a suggestion is simply 100% at-odds with the flaws it will create and there's no real middle ground.  Sometimes it is possible to discuss possible flaws and drawbacks and to work around them to a modified idea that addresses them well.  You never know that until you actually discuss the matter.

 

This specific idea does not seem to have a means of mitigating the problem it would introduce, which means choosing between being significantly more inconvenienced or abandoning a current playstyle if you want the added protection or choosing to leave yourself vulnerable and continuing to fall victim to the issue this seeks to address.  Therefore, while I would not be opposed if this were introduced in tandem with other solutions, I cannot support this idea over something like optional halting of views in trades should TJ only wish to pick one idea--which would solve both the issue of trades being spoiled and would not introduce the issue of "choosing between your current playstyle and trade protection".

 

Except that you are ENTIRELY missing the point here.  People are already having to choose between you have to choose between preferred playstyle and protection.  Multiple people have mentioned hiding their scrolls entirely to make it harder to viewbomb.  Viewbombing is literally already majorly negatively impacting how people play the game and FORCING gameplay changes on them.

 

We already have the security option to toggle on/off of entering password confirmation to use BSAs and such.  This is already what you describe as having to "either forfeit protection or have to reenter your password frequently" and I don't see people taking an issue with it.  I'm seeing people taking an issue with a proposed change for reasons that are presumed to be bigger issues than they would be or already are.  It's turning things into an "us or them" argument assuming things about what TJ can or can't do without any input from TJ himself.  For all we know, one of these might be super easy to code and the other insanely difficult.  If that's the case, it's better to support BOTH so that at least one does get implemented (whichever is easier) while keeping the other on the radar for the future.

 

And besides, while viewbombing in trades is one of the things I mentioned, I also specifically mentioned for just eggs on one's scroll in general.  Which has happened to me, repeatedly now, in the last 48-hour period.  I'm sure you would agree that this is completely unacceptable. One way or another, action needs to be taken, because it's far, FAR too easy to viewbomb dragons, whether they're in a trade or not.  Heck, I've had one viewbombed because someone else happened to go for a rare egg at the same time I did, but I beat them to the punch... while the other person proceeded to take the egg code from the url and add it to hatcheries.  This is absolutely a thing that happens!  Protecting trades alone won't prevent this, but like I said, I see no reason not to support BOTH options so that either (or both) can be implemented at TJ's discretion.

[Fuzzbucket]

So what is so terrible about simply hiding your scroll ? And:

 

2 hours ago, ACDragonMaster said:

And besides, while viewbombing in trades is one of the things I mentioned, I also specifically mentioned for just eggs on one's scroll in general.  Which has happened to me, repeatedly now, in the last 48-hour period.  I'm sure you would agree that this is completely unacceptable.

 

It has been shown many times that saying this kind of thing in a forum thrashed frequently leads to - viewbombing. Which is very easy to do without the API or hatcheries.

[_Charky]

This is already an existing feature. Anyone with API access (which you need to have to run a clicksite) is able to implement login verification. A few of the sites have the feature already. TJ's done everything he would need to do on his end; it's the people who maintain the hatcheries who you should be messaging about this and asking them to implement it.

[KageSora]

On 1/1/2023 at 12:05 AM, ACDragonMaster said:

 

Except that you are ENTIRELY missing the point here.  People are already having to choose between you have to choose between preferred playstyle and protection.  Multiple people have mentioned hiding their scrolls entirely to make it harder to viewbomb.  Viewbombing is literally already majorly negatively impacting how people play the game and FORCING gameplay changes on them.

 

Then I fail to see why this suggestion has any merit.  What adding this safeguard in as it is proposed is, in effect, saying is "we want protections but only for some players and those who have a playstyle that would be significantly inconvenienced by this safeguard should simply get a different one or should just continue to be at risk of getting their stuff messed up by other players".

 

That is why I prefer the optional addition to Teleport to pause views on dragons that are in a trade.  It would grant the same protections against having trades spoiled or dragons killed via viewbombing things that are in trade without adding entirely new layers of frustration to people based on their playstyle or forcing them to simply be unable to take advantage of the added protections at all.

 

On 1/1/2023 at 12:05 AM, ACDragonMaster said:

We already have the security option to toggle on/off of entering password confirmation to use BSAs and such.  This is already what you describe as having to "either forfeit protection or have to reenter your password frequently" and I don't see people taking an issue with it.

 

Actually, I've definitely seen people suggest the ability to disable. that.  So, people do take issue with it at least occasionally.

 

On 1/1/2023 at 12:05 AM, ACDragonMaster said:

If that's the case, it's better to support BOTH so that at least one does get implemented (whichever is easier) while keeping the other on the radar for the future.

 

That's a matter of personal taste.  I will not support multiple suggestions if one of those suggestions means adding frustration to my ability to play the game and the other does not.  I would, quite frankly, rather see the game continue on as it currently is without any added protection than see this specific suggestion implemented on it's own.

 

On 1/1/2023 at 12:05 AM, ACDragonMaster said:

assuming things about what TJ can or can't do without any input from TJ himself.

 

And as we don't have any way of knowing without TJ himself coming and saying one way or the other (which is not something he does in every single topic that comes up) what he is willing and/or able to do, then I prefer to err on the side of assuming less than assuming more.  Supporting your argument with "well why not both" is assuming that getting both is a strong possibility and we have no way to know if that's true or if that has zero chance of happening.  It might be!  And as I said, if so, then I wouldn't have an issue with this being added alongside other protections to accommodate different playstyles.  But without confirmation on that specifically, I don't feel like pinning my hopes of this problem being solved on something that I will not be able to take advantage of without changing how I play.

 

On 1/1/2023 at 12:05 AM, ACDragonMaster said:

And besides, while viewbombing in trades is one of the things I mentioned, I also specifically mentioned for just eggs on one's scroll in general.  Which has happened to me, repeatedly now, in the last 48-hour period.  I'm sure you would agree that this is completely unacceptable. One way or another, action needs to be taken, because it's far, FAR too easy to viewbomb dragons, whether they're in a trade or not.  Heck, I've had one viewbombed because someone else happened to go for a rare egg at the same time I did, but I beat them to the punch... while the other person proceeded to take the egg code from the url and add it to hatcheries.

 

For individual dragons we already have a solution to that--you can fog them.  If you get a dragon that you are not trying to trade (at least not at the moment) and you don't want to risk it being viewbombed then you can fog it immediately.

 

On 1/2/2023 at 8:36 AM, _Charky said:

This is already an existing feature. Anyone with API access (which you need to have to run a clicksite) is able to implement login verification. A few of the sites have the feature already. TJ's done everything he would need to do on his end; it's the people who maintain the hatcheries who you should be messaging about this and asking them to implement it.

 

OP wants the API to force the login verification and refuse to allow them to have your scroll--or individual dragon codes--added without it.  If other fansites decide to do it, there's not much to be done about how annoying it can be.  But I'd rather that be their choice so I can try and find less frustrating ones to use than have the game itself force that.

 

On 1/1/2023 at 3:03 AM, Fuzzbucket said:

It has been shown many times that saying this kind of thing in a forum thrashed frequently leads to - viewbombing. Which is very easy to do without the API or hatcheries.  Which is very easy to do without the API or hatcheries.

 

Yeah, which is really just vile and petty.  Pretty low behavior to take their dislike of somebody's opinion out on them like that instead of leaving it to a textual disagreement, IMO.  But also, you're right about other methods as well--people tend to forget that there are other ways of doing it.

[MissK.]

24 minutes ago, KageSora said:

OP wants the API to force the login verification and refuse to allow them to have your scroll--or individual dragon codes--added without it.  If other fansites decide to do it, there's not much to be done about how annoying it can be.  But I'd rather that be their choice so I can try and find less frustrating ones to use than have the game itself force that.

 

The suggestion is to force the login verification for all fansites if the DC user in question has opted into that feature. It would not remotely affect anyone who doesn't want that.

 

I see no issues with this suggestion personally. It's optional, and would indeed offer a higher level of protection regardless of which fansite(s) one uses, so support. It's just up to TJ if it's possible/appropriate, but isn't that the case for all suggestions?

 

Edit: To clarify a bit more why this makes sense to me. I hate it when I hide my scroll to avoid viewbombing, because one of my main forms of hunting is the AP so I catch-incubate-ER eggs a lot. That takes considerably longer without access to all fansites to hatch my eggs faster, especially since often I want them hatched in a timely manner to offer on a trade. I think it's very annoying that the only way to protect ourselves is hiding our scroll, which isn't even foolproof if someone has codes to add to fansites, while also having the added inconvenience of not being able to use several fansites for ourselves either. This suggestion would make things much easier for those of us who don't want to hide our scroll or don't consider that safe enough, without affecting anyone who doesn't want to use the feature.

Edited January 4, 2023 by MissK.

[KageSora]

52 minutes ago, MissK. said:

 

The suggestion is to force the login verification for all fansites if the DC user in question has opted into that feature. It would not remotely affect anyone who doesn't want that.

 

I see no issues with this suggestion personally. It's optional, and would indeed offer a higher level of protection regardless of which fansite(s) one uses, so support. It's just up to TJ if it's possible/appropriate, but isn't that the case for all suggestions?

 

Edit: To clarify a bit more why this makes sense to me. I hate it when I hide my scroll to avoid viewbombing, because one of my main forms of hunting is the AP so I catch-incubate-ER eggs a lot. That takes considerably longer without access to all fansites to hatch my eggs faster, especially since often I want them hatched in a timely manner to offer on a trade. I think it's very annoying that the only way to protect ourselves is hiding our scroll, which isn't even foolproof if someone has codes to add to fansites, while also having the added inconvenience of not being able to use several fansites for ourselves either. This suggestion would make things much easier for those of us who don't want to hide our scroll or don't consider that safe enough, without affecting anyone who doesn't want to use the feature.

 

So making things easier for one group by shifting the frustration and annoyance in order to have security (or just continue facing zero protections to avoid the added hassle) to another group is an acceptable tradeoff in your opinion.

 

I cannot support this for that reason.

[Fuzzbucket]

I don't think anyone should FORCE fansites - set up by individuals - to do this. and as Charky says, in any case

 

On 1/2/2023 at 2:36 PM, _Charky said:

This is already an existing feature. Anyone with API access (which you need to have to run a clicksite) is able to implement login verification. A few of the sites have the feature already. TJ's done everything he would need to do on his end; it's the people who maintain the hatcheries who you should be messaging about this and asking them to implement it.

 

While I deplore viewbombing - and it has happened to me - we can manage to keep our scrolls safe by hiding them when we aren't actually playing.

 

And I reiterate - players who come here and say a lot about how awful it is do usually get bombed.

Which - well, would possibly explain this "last 48 hours" thing !

 

On 1/1/2023 at 6:05 AM, ACDragonMaster said:

And besides, while viewbombing in trades is one of the things I mentioned, I also specifically mentioned for just eggs on one's scroll in general.  Which has happened to me, repeatedly now, in the last 48-hour period.  I'm sure you would agree that this is completely unacceptable.

 

 

5 minutes ago, KageSora said:

 

So making things easier for one group by shifting the frustration and annoyance in order to have security (or just continue facing zero protections to avoid the added hassle) to another group is an acceptable tradeoff in your opinion.

 

I cannot support this for that reason.

 

I am 100% with you.

[MissK.]

1 hour ago, KageSora said:

 

So making things easier for one group by shifting the frustration and annoyance in order to have security (or just continue facing zero protections to avoid the added hassle) to another group is an acceptable tradeoff in your opinion.

 

I cannot support this for that reason.

 

I never said that, I just don't understand what group you are talking about. Who faces frustration and annoyance? It's a suggestion that would improve things for whoever wants to use it, or not change anything for anyone who doesn't. Do you mean that the group of people who doesn't want to use this would somehow be more frustrated than they already are...?

[Fuzzbucket]

If all fan sites HAVE to require you to log in, and you want to use several at once to incu hatch AP stuff - and you don't want to be logged into all of them all the time, it would be a bit of a pain. And - it will not stop viewbombing. That is SO easy to do without using a fan site.

[KageSora]

39 minutes ago, MissK. said:

I never said that, I just don't understand what group you are talking about. Who faces frustration and annoyance? It's a suggestion that would improve things for whoever wants to use it, or not change anything for anyone who doesn't. Do you mean that the group of people who doesn't want to use this would somehow be more frustrated than they already are...?

 

What happens to players who want and need that extra protection, but don't want the hassle of entering their password into a hatchery dozens of times in a short period of time as they repeatedly update their scroll because they're doing extensive AP incuhatchable hunting and shuffling things around over and over again?

 

What happens is either we give up our playstyle while trading, or we have to enter passwords repeatedly, every single time we want to update any fansite with our scroll.  That's extremely annoying to do.

 

That or we get zero added protection and the game basically says "if you want protection, get a new playstyle".  At which point this suggestion is completely worthless for us, and may as well not exist at all.  So, in effect, shuffling the existing annoyance of players who have their scrolls hidden and can't just add them easily to fansites off to players who do not want to have to repeatedly enter their password every single time they try to update their scroll on any fansite but now have to in order to have any kind of protection.

 

Protection which won't actually 100% stop these issues, by the way.  You can still get viewbombed without a fansite being used at all.

[MissK.]

What I mean is, those people already are in this situation, it wouldn't suddenly happen because of this suggestion. I personally also support the protected trades idea, because it offers a different benefit altogether. But this suggestion would protect everything on people's scrolls, not just the items on a teleport link. And it kind of makes sense that there's a bit of a trade off for this extra safety (putting in our password, just like to perform actions such as abandon/freeze/kill etc.). These suggestions have different functions, and are definitely not mutually exclusive. Supporting one does not mean you support the other any less. If this suggestion wouldn't benefit you it's totally fine to not support it of course, but I don't think it would have some kind of horrible effect on people who just choose not to use it. 

[KageSora]

4 minutes ago, MissK. said:

What I mean is, those people already are in this situation, it wouldn't suddenly happen because of this suggestion.

I'm not, actually, currently in the situation of the game telling me "yeah, we have built in protections to reduce the risks you face--but you can't use them AND keep going with your existing playstyle without a major trade-off in terms of annoyance, so get a new playstyle or suffer".  This suggestion, if implemented, would put me in that situation.  I don't think shifting that situation to a new group of players instead of trying to come up with a solution that reduces frustration for everyone is useful.

 

The neat thing about the teleport link is that you could just shove things you have no intention of trading in it and set it to pause views, or you could fog things to protect individual dragons.

[MissK.]

17 minutes ago, KageSora said:

The neat thing about the teleport link is that you could just shove things you have no intention of trading in it and set it to pause views, or you could fog things to protect individual dragons.

 

But this is a loophole, I severely doubt it would pass as an intended feature. Trading is for trading, not for protecting your eggs with no intention to trade, especially if it's only applied to public teleports as has been suggested. Regardless, this is not the thead for this discussion so I shouldn't get us even more off topic.

 

Personally I think it would be good to have anything that would give at least the option of additional protection, yes with the trade off of a bit of extra effort. It would still be far less effort than hiding my scroll and having to unhide it every time I want to use fansites. There isn't currently another suggestion that offers full scroll protection like that (that I know of,  feel free to link me!) so I support this. You don't seem to see it that way so we might have to agree to disagree. 

[Fuzzbucket]

4 minutes ago, MissK. said:

But this is a loophole, I severely doubt it would pass as an intended feature. Trading is for trading, not for protecting your eggs with no intention to trade, especially if it's only applied to public teleports as has been suggested. Regardless, this is not the thead for this discussion so I shouldn't get us even more off topic.

 

This - and it needs mentioning in this thread so that the loophole doesn't get set up by accident. You can fog indivdual things you don't plan to trade, to prevent views,.

[_Charky]

With my explanation, I was referring to OP's actual suggestion of how to code it:

On 12/31/2022 at 6:51 AM, ACDragonMaster said:

 have an option that can be enabled on user accounts to require password authentication when adding a scroll/dragons to a click site.

 

Yes, I realize that this would require some overhauling to the API, but I know this sort of thing can be done (the usual method would be that the other site--a click site in this case--passes you back to dragcave.net where you're required to enter your password similar to doing so for BSAs, then dragcave passes this info back to the click site which now allows you to add your dragons).

...

People who don't want their scrolls messed with can opt in, and it could be automatically disabled if someone chooses the option to allow help from others.

Which is EXACTLY the process which is followed currently, when a site offers scroll protection... Although we can't access "allows help" information about a scroll, much like we can't access breed information (yet), or egg sickness status (because "third-party sites shouldn't be obviating the need to raise your eggs yourself"). The API is curated, it's not just comprehensive access to the entire user database. It could possibly be addressed, but people have been asking for the breed data for years and all TJ's said is "at some point".

 

With regard to....

3 hours ago, KageSora said:

OP wants the API to force the login verification and refuse to allow them to have your scroll--or individual dragon codes--added without it.

This isn't really how this works.

When you call the API, it just tells you information about the user / code you've entered. That information COULD, theoretically, include a "Scroll Protected" variable that tells the API whether you want to use scroll protection or not, but it doesn't in any way prevent the clicksites from failing to use that data.

 

You don't even NEED the API to add eggs. You just display the egg image and optionally add a link to it around the egg. The API access is so you can get all of a person's eggs at once, or to verify that the creature exists. The only way to stop the clicksites from adding protected scrolls is to stop them from seeing any dragon information AT ALL without logging in first. That means you couldn't use lineage previewers or tools like FART without logging in, either.

 

The current process goes very much how I've outlined above:

1. User inputs scroll name
2. hatchery asks DC for information about user
3. DC provides the information
4. hatchery offers it up for scroll management

When you build in scroll verification:

1. User inputs scroll name
2. hatchery checks if scroll is protected (during a call it would already be making to check what's in the database)
   1. (optional)hatchery redirects to DC login page
   2. (optional)DC Redirects to hatchery after successful login
3. hatchery asks DC for information about user
4. DC provides the information
5. hatchery offers it up for scroll management

With the theoretical forced scroll verification:

1. User inputs scroll name
2. asks DC if the user has scroll protection turned on (a call it didn't have to make when using its own check)
   1. (if protection is on) DC responds to hatchery saying verification is required
   2. (if protection is on) hatchery redirects to DC for login
   3. (if protection is on) DC Redirects to hatchery after successful login
3. DC Redirects to hatchery saying "you can request information now"
4. Hatchery has a think about whether it needs to provide evidence of authorisation to see eggs or not
5. hatchery asks DC for information about user
6. DC provides the information
7. hatchery offers it up for scroll management

Do you see how it's getting more complicated / further from the existing code (and thus, harder to code, slower to process/load, and more likely to kill hatcheries) as we add more verification steps?

 

3 hours ago, KageSora said:

If other fansites decide to do it, there's not much to be done about how annoying it can be.  But I'd rather that be their choice so I can try and find less frustrating ones to use than have the game itself force that.

I intend to have scroll protection activated as standard, with an option to disable it per-user once you log in for the first time. Other sites could quite easily do the same, as long as it's left up to them; if it's not, some will probably shut down rather than having to re-write their entire scroll management process.