Does instant feedback work (anymore)?

[qidniz]

Threads on AH indicate that the feedback feature "Send instant feedback to ..." on an author's About page used to work in the past.

Does it still work?

If not, when did it stop working? Could this be a victim of the change to the new (beta) version of the front end (considering that the link goes to an old-style page/form handled by a PHP script)?

 

[SavannaT]

I miss quick feedback .. its gotten to the point that even when feedback to my stories is bad im excited to read it

 

[THBGato]

I got a feedback email last week, so I think it's still working

We can test if you like - go read one of my stories and send me some feedback about it, and I'll let you know if it comes through.

 

[BeechLeaf]

It's not instant, but the delay is the usual one for most things here: the e-mail arrives about a day later. I have tested this, but I've also seen reports here that some e-mail suppliers might suppress e-mails from Literotica.

 

[TheLobster]

I got one a few days ago. Using Proton, so I doubt they’re suppressing anything.

 

[ElectricBlue]

Threads on AH indicate that the feedback feature "Send instant feedback to ..." on an author's About page used to work in the past.

Does it still work?

Yes. I got a feedback message a couple of weeks ago, after I commented on someone's new story. They've always thanked me via Feedback rather than a PM, whenever I comment.

No change in the feedback mechanism in the twelve years I've been here.

There might be delays getting through servers, but how would anyone know?

 

[qidniz]

It's not instant, but the delay is the usual one for most things here: the e-mail arrives about a day later.

That's very odd, unless they're moderating such mail. (But then, why?) Ordinarily, there should be no human involved in email delivery. I can understand delays of up to a few hours (network glitches) but a full day would be very unusual, if not suspicious.

I have tested this, but I've also seen reports here that some e-mail suppliers might suppress e-mails from Literotica.

I think Yahoo is one such. I tried registering an alternate identity with a Yahoo address, and never got the confirmation email. That "account" is DOA.

My own test involved an inactive account I created many years ago (and forgot about) using Yahoo, back when that worked. I can login to the account here, but sending test feedback from that account to my active account vanished into the ether, as did sending a message the other way (which did not surprise, given the experience with Yahoo.)

Those tests were two days ago. Maybe I should give it a few more days.

 

[usable001]

There might be delays getting through servers, but how would anyone know?

I participated in a test a few days ago. There was a delay of about a day, but the feedback got through.

 

[Britva415]

That's very odd, unless they're moderating such mail. (But then, why?) Ordinarily, there should be no human involved in email delivery

The email isn't getting sent until after the delay.

I doubt it's moderation. I think it's more likely a batch process: the application stores the message until some scheduled time when it sends all of the accrued ones at once. Before this point, they aren't emails at all, they're just data the application collected.

Pretty typical of decades-old application architectures. And certainly typical of lots of things on the website which don't update in real time.

 

[AStrangeDesire]

It worked yesterday. Agree with @Britva415, most likely batch processing. Possibly with scanning for spam urls? That last bit might be wishful thinking on my part

 

[BeechLeaf]

What I was testing was the different feedback links: envelope at the top of a profile, 'instant' feedback at the bottom, and something at the end of each story. Incidentally, waiting for results, I found it was a full day rather than instant or an hour or two.

Yes, I think I read here that Yahoo suppresses Literotica messages. My test target was Proton. I'm impressed by Proton. When I wanted to sign up here about six months ago, I just wanted a simple anonymous e-mail account, so I searched for {free e-mail} or whatever and the name Proton came up. Never heard of it. I was prepared to waste lots of time trying sites that demanded telephone number, facial recognition, blood swab, firstborn child wrapped in masking tape, etc. but Proton just said, 'Yeah okay, you want to register that name? Give us a password. No, any password, doesn't have to include glottal stops and flags of all nations. Yeah, that one's fine. Right, you're in.' This could have indicated it was shonky and insecure, but since then I've learnt it has quite the reputation.

 

[ElectricBlue]

I doubt it's moderation. I think it's more likely a batch process: the application stores the message until some scheduled time when it sends all of the accrued ones at once. Before this point, they aren't emails at all, they're just data the application collected.

Agree. Before assuming anything nefarious, wait at least 24 hours. Nothing is in synch on this site, never has been and I doubt, ever will.

I've just responded to a comment under one of my stories, with another comment. My comment shows under the Works sort on my CP, so I know it's posted, but it doesn't show under the story yet, nor in my CP feed.

This, to me, is the usual and normal timing, and it never occurs to me to think, ooo, danger, Will Robinson.

This site reinforces the old project manager's notion: never assume malice when a fuck-up is a perfectly good explanation. Seems to me too many people want to attribute active malice to what goes on in the machinery, when really, it's just clunky cog wheels going round.

 

[AStrangeDesire]

What I was testing was the different feedback links: envelope at the top of a profile, 'instant' feedback at the bottom, and something at the end of each story. Incidentally, waiting for results, I found it was a full day rather than instant or an hour or two.

Yes, I think I read here that Yahoo suppresses Literotica messages. My test target was Proton. I'm impressed by Proton. When I wanted to sign up here about six months ago, I just wanted a simple anonymous e-mail account, so I searched for {free e-mail} or whatever and the name Proton came up. Never heard of it. I was prepared to waste lots of time trying sites that demanded telephone number, facial recognition, blood swab, firstborn child wrapped in masking tape, etc. but Proton just said, 'Yeah okay, you want to register that name? Give us a password. No, any password, doesn't have to include glottal stops and flags of all nations. Yeah, that one's fine. Right, you're in.' This could have indicated it was shonky and insecure, but since then I've learnt it has quite the reputation.

I'd recommend either protonmail or tutanota to anyone looking for a reasonably secure, private email address. Glad you found proton

 

[BeechLeaf]

In theory Laurel could be using the delay to jot down all our secrets in a spiral-bound notebook. But never attribute to malice, etc. Also, we're thinking of messages that people in the AH send each other:

'I think the semicolon enhanced the alliteration of the asyndeton.'

But people in other subforums also send messages, but most of them would be obscured by Laurel throwing up over her screen if she read them.

 

[qidniz]

I think it's more likely a batch process: the application stores the message until some scheduled time when it sends all of the accrued ones at once. Before this point, they aren't emails at all, they're just data the application collected.

That would be stupid. Batching mail makes little sense, if any at all. The only thing I can think of offhand is having to pay separately for each TCP connection(!) to one's mail server, something that was possible in the bad ol' days of dial-up with uucp or slip. 1998 isn't old enough for that.

Pretty typical of decades-old application architectures.

I respectfully disagree. 30 years ago, sending off email was trivial. All complications are quite modern in origin.

 

[ElectricBlue]

That would be stupid. Batching mail makes little sense, if any at all. The only thing I can think of offhand is having to pay separately for each TCP connection(!) to one's mail server, something that was possible in the bad ol' days of dial-up with uucp or slip. 1998 isn't old enough for that.

I respectfully disagree. 30 years ago, sending off email was trivial. All complications are quite modern in origin.

You're looking at everything with a 2026 perspective of instant action and response, but you're trying to convince people who have been here a decade or two that batching makes no sense. Every bit of technical evidence I've picked up over time, says a whole bunch of stuff on this site is batched, or runs once a day.

It's part of the furniture for me, that the site's clocks aren't in synch (they never have been), and a whole bunch of stuff gets batch processed (possibly linked to a 24 hour synch, I don't know).

It's pretty obvious to me that Lit is a legacy site, with all of the operational issues that implies, and the code is ragged, doesn't always join up. It's like any system that's been running for 25 years: hard to keep current.

 

[qidniz]

You're looking at everything with a 2026 perspective of instant action and response, but you're trying to convince people who have been here a decade or two that batching makes no sense.

I didn't say batching makes no sense. I said batching mail makes no sense. In fact it didn't make sense in 1998, so age of the software is no excuse here.

Every bit of technical evidence I've picked up over time, says a whole bunch of stuff on this site is batched, or runs once a day.

Batching makes a lot of sense when it comes to updating the site. I wasn't arguing against batching per se (that would be stupid too.)

It's like any system that's been running for 25 years: hard to keep current.

Deliberate stupidity - assuming that's the diagnosis - indeed needs extra work to keep up.

 

[ElectricBlue]

I didn't say batching makes no sense. I said batching mail makes no sense. In fact it didn't make sense in 1998, so age of the software is no excuse here.

Batching makes a lot of sense when it comes to updating the site. I wasn't arguing against batching per se (that would be stupid too.)

Deliberate stupidity - assuming that's the diagnosis - indeed needs extra work to keep up.

You're a bit harsh, accusing a mom and pop site of deliberate stupidity. Accidental maybe, in the face of adversity, but I don't see malice, never have.

I've seen far worse in fully funded, "properly developed" systems, including weapons and transport software systems, where negligence really does matter (which it doesn't, here).

 

[TheExperimentalist]

I participated in a test a few days ago. There was a delay of about a day, but the feedback got through.

(Can confirm, it took about a day.)

 

[qidniz]

You're a bit harsh, accusing a mom and pop site of deliberate stupidity. Accidental maybe, in the face of adversity, but I don't see malice, never have.

In the early '00s, L&M found someone to set up a proper site for them (up until then, it had been a true mom and pop operation). Someone with enough nous to set up a proper website would not have been clueless enough to batch email. It would take cluelessness of truly uncommon order to complicate one of the simplest tasks on the internet since its inception. I meant 'deliberate' in that sense. I wasn't trying to imply malice.

 

[qidniz]

What I was testing was the different feedback links: envelope at the top of a profile, 'instant' feedback at the bottom, and something at the end of each story.

The envelope icon and the 'instant' link on the About page invoke the same PHP script. One working but not the other would be decidedly odd. The private feedback link on the last page of a story invokes another script, so that could make a difference.

Incidentally, waiting for results, I found it was a full day rather than instant or an hour or two.

Fascinating.

 

[qidniz]

We can test if you like

Thank you. I've taken up the offer, and used the two different means - one story specific and the other from your About page.

 

[Britva415]

That would be stupid. Batching mail makes little sense

Don't think of it as "mail." It isn't mail until it is mail. Until then, it's just data in a homegrown application running on a 20 year old stack, and that application might have more important jobs to do with the available resources.

Back then, you had to optimize your custom application for different things than you optimize for today, and batch processing of all kinds of things was very common - including the sending of email messages. And we know Literotica.com has layers of heavy optimization. All the caching is a symptom of the same state of the art.

I'm not going to get into why simply asking the application to send each message to the email server in real time might not have been optimal compared to batching them, I just know that it wasn't far fetched at all back then. The email server wasn't/isn't the obstacle, even 20 years ago email servers were very good at sending messages in real time. The application routine which tells the email server to send you the message is the obstacle, and batching messages can make the application far more performant, when your measure of performance is something other than, something more important than, hitting inboxes in real time.

Batching one type job was an extremely common way to get another job to perform adequately. It was usually a response to fixing something else that badly needed the resources. Maybe even everything else. A crash means no jobs get any resources at all. Not even simple page views.

 

[THBGato]

Thank you. I've taken up the offer, and used the two different means - one story specific and the other from your About page.

Yep, received both about 4 hours ago.

 

[qidniz]

Back then, you had to optimize your custom application for different things than you optimize for today, and batch processing of all kinds of things was very common - including the sending of email messages.

I'm sorry, but I'll have to ask for evidence. Please name at least one program or system that batched the "sending of email messages" - understood to mean introducing messages into the mail delivery system from some other storage system. The earliest period in question is the early '00s, which is when Lit started as a proper website using the services of a (presumably professional or at least competent) developer.

By that time, Daniel Bernstein's qmail had become a serious competitor of Eric Allman's venerable sendmail. Both were extraordinarily sophisticated systems (and free!). No developer worth the name would even think of trying to reproduce the solutions these programs implemented to make sending mail as easy as possible. You let the mail delivery system - sendmail or qmail or their emerging competitors (including Microsoft Exchange for NT boxen) - worry about things like slow or dropped connections, spooling, concurrency, naming temporary files, whatever could go wrong. This was a solved problem by 1990 or so. (The O'Reilly book on Sendmail in 1993, a trade paperback, was over 800 pages! It was the second fattest book on my tech shelf, and the fattest paperback..) Not to take arms against the sea of troubles, and instead implement ones own homegrown system of "batching" (enormous complexity lies hidden behind such a simple word) would have been beyond batshit crazy. It would lose on all grounds, including efficiency, economy, and simplicity.

I'm not going to get into why simply asking the application to send each message to the email server in real time might not have been optimal compared to batching them, I just know that it wasn't far fetched at all back then.

I'm sorry, it was indeed far-fetched back then.

A crash means no jobs get any resources at all. Not even simple page views.

Which is exactly why one would pass messages as expeditiously as possible to the mail delivery system, which would have had a far better crash safety record than any home grown alternative.

I think you're arguing from general principles - yes, batching is a Good Thing - without much domain knowledge in this case.

I'm now just about convinced that these private messages are also reviewed. Nothing else could sensibly explain the delays (in the sense of being the prima facie reason for batching.)