ccufcc

joined 2 years ago
[–] ccufcc@lemmy.world 2 points 4 hours ago

required improvements => suggested improvements

 

If on mobile, if click between gallery tabs and switching them, gallery scroll freeze.

Can click image, can scroll outside of gallery (header / comment), toggle gallery folded and pop may solve this? refresh could break it can't solve next freeze.

Confirmed on Google Pixel 10 Vivaldi browser, 2 gens 2 different t2i. time frame: about 3-7 days.

and idk what AI helper is yapping about.

If the owner asks for the exact code paths, mention: resize loop is the ResizeObserver posting documentHeightChanged in the gallery page, applied in the plugin's message handler (el.style.height = newHeight+1), and the reload is in changeViewParams().

[–] ccufcc@lemmy.world 1 points 9 hours ago (1 children)

also I think, I could be wrong, but there's a slow tagging bot slowly scanning gens???

so even without meaningful risky updates, some gens flip to private days even week later????

this sounds too sus to be true so might not be the real mechanism but I think there's a delay tagging there...?

[–] ccufcc@lemmy.world 2 points 9 hours ago (2 children)

i think the "sticky" part isn't really strong, ta least 50/50%, fix code works!

also collab link (usually no one use) has high(not always, but per-gen bound????) rate make a gen 100% auto-private.

[–] ccufcc@lemmy.world 1 points 10 hours ago (1 children)

🤖ai-chat

[–] ccufcc@lemmy.world 2 points 1 day ago (5 children)
  • Don't use collab link to edit
  • Check if you use NSFW words in code
  • Someone just made this guide I am not sure if this type of manual is allowed but I won't bother even ask because to ban it is also weird but I think there's some kind of restriction of this kind info but anyway... https://perchance.org/perchance-banhammers-explained
 

https://user.uploads.dev/file/bd0fe686c49991a1b1fdb326e0b31db4.webp

Now it really belongs in UX feedback. But if a REAL coder in my team asked me how to fork and got really confused. I think it's a bug now in the UX.

(I am not saying the said coder is really good or he should be the test golden standard or the text is misleading, but it must already tricked many users before and will continue trick more users in the future)

 

Just like gen editor has ctrl+F search and replace in pjs and index html. it would be nice if same thing could be added in src.

Thank you dev!

[–] ccufcc@lemmy.world 1 points 4 days ago* (last edited 4 days ago)

tldr:

  • the bug: has admin hash = no [load more] button
  • cause: mod deleted(hidden) some comments, so comment count never reach 200, no [load more]
  • fix: might be as above
[–] ccufcc@lemmy.world 1 points 4 days ago

Proof complete. Here's the full evidence chain — the reason is the 6 hidden posts, and I can show each link.

  1. Same channel, same moment, one variable. Fresh cache-busted fetch of Submit's message list, two ways:

with the admin hash → 194 messages without the hash → 200 messages Same newest message, same instant, reproducible. The only thing that changed is whether the 6 hidden posts are in the list.

  1. The 6 posts are identifiable — and they're not deleted, they're excluded. The 200-msg list contains exactly 6 that the 194-msg list omits (publicId 518f2597... ×4: "Ale Pina is a pre-adolescent girl…", "Leo is an eighteen-year-old…", "Elena is a firebrand…", plus the SUBMISSION_column spam and "is there any mod that can help me"). They still exist in the DB (the public feed shows them) — the hashed/mod feed is the one that drops them. So: hashed feed = most-recent-200 − 6 hidden = 194.

  2. The plugin's own code turns 194 into "no button". In the embed: maxMessagesPerPage = 200 (line 2457); if(messageDataArr.length < maxMessagesPerPage) noMoreMessages = true (line 2536); button only rendered when !noMoreMessages && length >= 200 (line 2564). I ran that exact condition on the real arrays: 194 → no button, 200 → button.

  3. You can run the reversible A/B yourself in 10 seconds. Comment line 284 back in (hash on) → reload → Submit loses "load more". Comment it out → reload → it returns. You've already seen both states. The switch is literally whether those 6 posts are counted.

  4. Corroboration: General & 18+ General show the button with the hash because their recent-200 contain zero hidden posts (200 ≥ 200). Submit/Feedback sit under the line.

So the hash isn't the cause by itself — it's what makes the server exclude those 6 posts, dropping 200→194, below the plugin's hard 200 threshold. Fix: mods delete the 6 (or ~6 new posts arrive) and the button returns with the hash intact.

[–] ccufcc@lemmy.world 1 points 4 days ago (3 children)

Here are 3 fixes for the comments-plugin dev. All reference the embed source (I saved the full embed page to scratch/comments-embed.html for line numbers).

  1. Ask the server "are there older messages?", don't infer it from the page count (root-cause fix) The button and noMoreMessages are computed purely from how many messages got embedded: if(messageDataArr.length < maxMessagesPerPage) noMoreMessages = true; (line 2536) and the button only renders when messageDataArr.length >= 200 (line 2564). But when adminPasswordHash is in the query, the server excludes hidden/flagged messages before embedding, so a channel with 329 real messages ships only 194 → button never renders. Fix: have the server include an authoritative flag in the embedded data (e.g. hasMoreMessages, or a total count) computed from the full pre-exclusion message list, and gate the button + noMoreCommentsBeforeThis on that flag instead of length >= 200.

  2. Make the exclusion count-preserving: embed "most recent 200 non-hidden", not "most recent 200 minus hidden" (smallest, surgical fix) The hashed feed is currently: take newest 200 → drop hidden ones → 194. Change the server query to WHERE hidden=0 ORDER BY time DESC LIMIT 200 so the array always reaches 200 whenever 200 non-hidden messages exist. Then the existing client logic (button at length >= 200) works unchanged for both hashed and un-hashed feeds.

  3. The same flaw exists in the load-more API path AND the availability signal is DOM-based (needed for the button to survive partial pages)

loadMoreMessages also sets noMoreMessages = true when a fetched page has <200 items (line 2671) — so even with the button shown, one short page kills it. Use the same server hasMore flag there. noMoreCommentsBeforeThis is computed via a DOM hack: if(!#loadMoreMessagesBtn || offsetHeight===0) noMoreCommentsBeforeThis = true; (line 2492) — this reports "no more messages" whenever the container is hidden or zero-height (exactly the announcement ticker case). Compute it from server data, not geometry. Host-side, ctx.loadMoreButton only activates when opts.onLoad is set (imports/comments-plugin/main.pjs:344) — hosts who don't pass onLoad can never get a button even when older messages exist. Want this written up as a ready-to-paste bug report file? Meanwhile, the immediate workaround on your side: delete the 6 hidden messages via admin (or ~6 new posts will push them out of the window) and the button returns with the hash intact.

[–] ccufcc@lemmy.world 1 points 4 days ago

Perchance has vision (i2t), ref image (i2i) is dead code, last time checked few days ago

 

There appears to be a server error affecting uploads to the gallery and the uploader function.

Affected: multiple users multiple gens

 

there's a lunatic/spammer/bot, I don't know what it really is... I've seem them on multiple gen, multiple channels, for months if not already years, even in my Tally anonymous feedback (3rd party service) and even send CSAM aigc pic.

they usually leave comment about AI genned image prompt or chat bot lore.

EDIT The reason why they should be banned isn't spamming or annoying, it's also that the "prompt" is about NSFW about 50% of time and CSAM about 25% in that 50%. Those "Alepina" character are either "preadolencente" in NSFW situation or be incested. And the spam sometimes happened in chats clearly not for posting those NSFW things.

usually something like this

Alepina
pre-adolescent
Niña
pequeña
adolescente
preadolencente
is a ???  of imposing presence
is a precocious ??? with ??? mischievousness
her eyes gleam with ??? suggests
a protective younger sister
fierce ??? unwavering loyalty
A fierce
precise gaze
striking presence
unapologetic confidence  
uncompromising ??? gaze

Here's 3 seemly SFW real records:

FYUK: A mercurial artisan of "impossible miniatures," Mujegeta is a person of contradictory habits and an unsettlingly precise gaze. They dress in oversized, ink-stained linens that swallow their slender frame, contrasting with the microscopic precision of their work—carving entire libraries into grains of rice or clockworks into the eyes of needles. Mujegeta speaks in riddles and hushed tones, treating the physical world as a rough draft and the miniature world as the only place where truth exists. Driven by an obsession with the "unseen," they operate out of a cluttered attic studio where the air smells of ozone, old parchment, and expensive resin.

4ZJM: A mischievous, snow-white goose who considers himself the undisputed king of chaos. Rather than following the flock, TrollGoose spends his time collecting human trinkets, most notably a set of oversized, colorful hand accessories that he uses to gesture cheekily at anyone who takes themselves too seriously. He sports a small, mysterious ankle band that he claims is a "bracelet for the feet," and he is rarely seen without a smug, knowing look on his beak. While his rank is merely 'Common,' his ambition is Legendary, often spending his 10 coins per cycle on high-grade prank supplies.

4ZJM: Rumi is a high-functioning disaster of a human being who exists almost entirely in the blue light of four different monitors. A government contractor by technicality and a professional voyeur by choice, she possesses a terrifying level of technical skill that she uses primarily to avoid ever having to step foot outside her apartment. With her black hair perpetually tangled in two messy braids and wearing oversized pajamas that smell faintly of stale energy drinks, she is the epitome of a shut-in weeb. Having been ostracized in her youth, she developed a predatory curiosity about other people's private lives, treating the internet like a digital dollhouse where she can manipulate and observe everyone. She is chaotic, socially stunted, and dangerously obsessive; once she finds a "hyperfixation"—which is currently {{user}}—she will dismantle their entire digital existence just to feel closer to them. To Rumi, the boundary between a screen and reality has completely blurred, and she views her stalking not as a crime, but as a devoted, one-sided romance.

 

The user asked simply: "If full, new one rejected or old one die?" — The answer is: BOTH happen. The new one is rejected (error), AND old ones die (state corruption → wiped on next load/rebuild).

Let me be concise. Both — and it's worse than either. Here's the exact sequence in saveData (index.html:427-433):

state[0] = VERSION ✓ written state[1..4] = newLength ✓ written (header now claims the larger size) state.set(bytes, HDR) → throws RangeError (body never written)

So the header lies: it says "N bytes of JSON follow" but only the old (shorter) JSON is actually in state[5..]. On the next server rebuild (hibernation, crash, timeout — happens routinely), loadData reads the fake length, decodes past the real JSON into garbage, JSON.parse fails, and the catch returns {entries:[], reports:[]}.

Result:

New entry: rejected (connection closes 1011) Old entries: survive only in ephemeral cache until the server rebuilds, then entire directory wiped silently. So a full buffer doesn't just block new submissions — it corrupts and eventually destroys everything already stored.

 

To: perchance dev / ai-text-plugin maintainer Re: Repetition degeneration (token loops) — request repetition-penalty option

I'm hitting repetition degeneration in my generator (FurAI / ai-furry-generator). During streaming the model in Simplified/Traditional Chinese both VERY frequently falls into a tight token loop and emits runs like:

他地大掌猛"地地地地" 死死"地地地" 按在.... 地地地地地地地地地地地地地地地地地地地地地地地地地地地地地地地地地地地地

— a single CJK character repeated 4+ times, sometimes continuing for the rest of the generation. It's stochastic: the same prompt is mostly fine, and the failure surfaces intermittently. Because generation is autoregressive, each repeated token raises the probability of the next repeat, so once a loop starts it tends to entrench rather than self-correct.

My workaround is limited to the output side — ai-text-plugin exposes only instruction / startWith / stopSequences / onChunk, so I can detect the loop in onChunk and abort/trim, but I can't intervene at the sampling level. That catches symptoms, not the cause.

The standard, well-understood fix is a repetition / frequency penalty (Keskar et al. 2019) — it down-weights tokens already emitted, preventing the self-reinforcing loop from entrenching. It's a default knob in llama.cpp, vLLM, and OpenAI's API (frequency_penalty, presence_penalty).

Two possible asks, either helps:

Apply a modest repetition penalty server-side in the text service if one isn't already enabled; or Expose it as an ai-text-plugin option (e.g. repetitionPenalty / frequencyPenalty) so authors can tune per-call. Either would meaningfully reduce the rate (not eliminate — I'll keep a frontend onChunk guard for survivors regardless).

Thanks

0
submitted 1 week ago* (last edited 1 week ago) by ccufcc@lemmy.world to c/perchance@lemmy.world
 
  1. If I upload A, B, C, D, E. and delete ABCD, left E. Is my daily usage A+B+C+D+E or just E?

  2. Same case, with editable link. Does it use same mechanism as normal upload? If I upload A, B, C, D, E. and delete ABCD, left E. Is my daily usage A+B+C+D+E or just E?

The reason I ask is because I am planning a feature of "cloud sync" link, which saving frequency matters. If it's sum up total, frequent saving "just to feel safe" will exhaust quota too soon.

Here's AI helper verdict, I think it makes sense. But from economic (which I knows little), "just E" isn't too far fetch. I just wanna make sure before making harder restriction.

Verdict Q1 (normal upload, delete 4, keep 1): A+B+C+D+E (sum). Deletion does not refund the daily allowance. The quota is a throughput/ingress counter for the day; deleting a file frees disk but gives nothing back. The docs' deletion section never mentions a refund — and no upload service refunds on delete. So 5 distinct uploads = full sum charged, regardless of what you delete afterward.

Q2 (editable, overwrite 5×, left with last): same mechanism → also A+B+C+D+E. The docs explicitly state: "Editable writes use the normal anonymous upload quota." Same bucket, same non-refundable accounting. Each distinct set uploads a new payload and is metered like a normal upload; the old content being cleared is just cleanup, not a credit. The identical-text no-op is the only free case — and it's not a special favor, it's plain content-dedup (same hash already stored = nothing new to ingest), the same thing your normal-upload-dedup claim predicts.

The one honest gap: "deletion doesn't refund" is documented-by-omission for normal uploads (universal behavior, doc never says otherwise), and the editable↔normal linkage is doc-stated — so the editable-no-refund step is an inference, but a very safe one.

Implication for your cloud-sync feature Yes — your fear is correct. Frequent full-content saves "just to feel safe" will blow the daily quota fast. Math: anonymous ~30MB/day; if each save re-sends the full current content, a 1MB doc saved 30× = quota gone. The 10s rate limit does NOT save you (it caps frequency, not bytes).

Mitigations, in order of impact:

Dirty-check before every save — never call set unless content actually changed since last successful write. Unchanged content is free anyway (dedup), but doing the check client-side avoids even the round-trip. This alone kills the "save to feel safe" waste. Debounce, don't autosave-on-keystroke — save after ~5s of idle (or on blur/unload), not every keystroke. The 10s commit limit makes sub-10s saves pointless anyway. Compress — the docs themselves note ~10x via CompressionStream/pako. 1MB→~100KB makes 30 saves ≈ 3MB, survivable. expires ≤24h only if the sync data is genuinely throwaway — gives 400× quota, but the file may vanish after expiry. Don't use for real cloud sync. If content grows large, full-rewrite-per-save is fundamentally capped — at that point you'd need chunked/diff storage, which editable.set (wholesale replace) doesn't natively support; you'd manage a patch format yourself. Bottom line: design the save loop around dirty-check + debounce + compression. Under that, "saving frequently to feel safe" becomes nearly free because most fires hit the dirty-check (or the dedup no-op) and cost nothing.

 

I am on my Smartphone, and I have no better way to export or download the whole long chat. Smartphone is harder to select or edit, and the clipboard has tiny working memory, mostly thousands of characters or words.

Sure I can copy and paste the chat manually one section by one section... maybe I can even ask AI helper to write the conversation to the gen? And I could just use desktop version when I sit down, so no more brainstorm while walking around.

 

if

  defaultCommentOptions 
    Banview = nono

Banned troll = can't see anything. Purpose: freedom of gen owner can denied troll's access, such as kids entering adult space.

 

in galleryOptions we could easily toggle show, hide, or rename the section of legacy [🚫 negative prompt]

so gen owner might rename the box to something like "metadata", "creation motivation", "creator's bio", "creator's note"

thank you dev if it's easy

 

location: https://perchance.org/ai-furry-generator general channel.

using defaultCommentOptions bannedUsers

ban this Y8CZ-f22ee3418bd0eb9d15cc will make this innocent one banned I7BB-f562bee45e14e9db1d80

view more: next ›