I’m beautiful and tough like a diamond…or beef jerky in a ball gown.

  • 134 Posts
  • 738 Comments
Joined 8 months ago
cake
Cake day: July 15th, 2025

help-circle







  • Audio transcribing should be the little “waveform” icon at the right of the text input:

    Image generation, I’m not sure as that’s not a use-case I have and don’t think the small-ish models I run are even capable of that.

    I’m not sure how audio transcribing works in OpenWebUI (I think it has built-in models for that?) but image generation is a “capability” that needs to be both part of the model and enabled in the models settings (Admin => Settings => Models)







  • 🤚totally guilty there.

    I wish there was a way to mute or turn off replies, and I might post more. Sometimes / often I’ll want to post something but definitely do not want to be bombarded with the comments it would generate. Other times, I’ll like the community but not be involved enough in whatever hobby to post anything but still enjoy seeing other people’s work (e.g. HAM radio, sewing, etc).




  • Disclaimer: : All of my LLM experience is with local models in Ollama on extremely modest hardware (an old laptop with NVidia graphics) , so I can’t speak for the technical reasons the context window isn’t infinite or at least larger on the big player’s models. My understanding is that the context window is basically its short term memory. In humans, short term memory is also fairly limited in capacity. But unlike humans, the LLM can’t really see (or hold) the big picture in its mind.

    But yeah, all you said is correct. Expanding on that, if you try to get it to generate something long-form, such as a novel, it’s basically just generating infinite chapters using the previous chapter (or as much of the history fits into its context window) as reference for the next. This means, at minimum, it’s going to be full of plot holes and will never reach a conclusion unless explicitly directed to wrap things up. And, again, given the limited context window, the ending will be full of plot holes and essentially based only on the previous chapter or two.

    It’s funny because I recently found an old backup drive from high school with some half-written Jurassic Park fan fiction on it, so I tasked an LLM with fleshing it out, mostly for shits and giggles. The result is pure slop that seems like it’s building to something and ultimately goes nowhere. The other funny thing is that it reads almost exactly like a season of Camp Cretaceous / Chaos Theory (the animated kids JP series) and I now fully believe those are also LLM-generated.






  • I used to buy their stuff and use tuya-convert to flash Tasmota onto them. But they kept updating the firmware to lock that out, and I ended up returning a batch of 15 smart plugs because none of them would flash. They were too much of a PITA to try to crack open and flash the ESP8266 manually so I returned the whole batch as defective, left a scathing review, and blackballed the whole brand.


  • Solutions that work for a corporate application where all the staff know each other are unlikely to be feasible for a publicly available application with thousands of users all over the world

    This is something of a hybrid. There will be both general public users as well as staff. So for staff, we could just call them or walk down the hall and verify them but the public accounts are what I’m trying to cover (and, ideally, the staff would just use the same method as the public).

    Figure if an attacker attempts the ‘forgot password’ method, it’s assumed they have access to the users email.

    Yep, that’s part of the current posture. If MFA is enabled on the account, then a valid TOTP code is required to complete the password reset after they use the one-time email token. The only threat vector there is if the attacker has full access to the user’s phone (and thus their email and auth app) but I’m not sure if there’s a sane way to account for that. It may also be overkill to try to account for that scenario in this project. So we’re assuming the user’s device is properly secured (PIN, biometrics, password, etc).

    If you are offering TOTP only,

    Presently, yes, but we’re looking to eventually support WebAuthn

    or otherwise an OTP sent via SMS with a short expiration time

    We’re trying to avoid 3rd party services, so something like Twilio isn’t really an option (nor Duo, etc). We’re also trying to store the minimum amount of personal info, and currently there is no reason for us to require the user’s phone number (though staff can add it if they want it to show up as a method of contact). OTP via SMS is also considered insecure, so that’s another reason I’m looking at other methods.

    “backup codes” of valid OTPs that the user needs to keep safe and is obtained when first enrolling in MFA

    I did consider adding that to the onboarding but I have my doubts if people will actually keep them safe or even keep them at all. It’s definitely an option, though I’d prefer to not rely on it.

    So for technical, human, and logistical reasons, I’m down to the following options to reset the MFA:

    1. User must contact a staff member during business hours to verify themselves. Most secure, least convenient.
    2. Setup security questions/answers and require those after the user receives an email token (separate from the password reset token). Moderately secure, less convenient, and requires us to store more personal information than I’d prefer.
    3. Similar to #2 except provide their current password and a short-term temporary token that was emailed to them when they click “Lost my MFA Device”. Most convenient, doesn’t require unnecessary personal info, possibly least secure of the 3. Note that password resets require both email token and valid TOTP token, so passwords cannot be reset without MFA.

    I’m leaning toward #3 unless there’s a compelling reason not to.