I detected a small bug that you might be interested in solving.
Yep. I know what you're referring to, and I get why you might consider that behavior to be a bug, but it's working as intended. I do agree that it's a little confusing for the highlighting to work with the "Last post" button but not with the "new" button (especially because, in some contexts,
both those links involve a
#new fragment, which is a detail that makes the explanation I gave Loyce at the bottom of
this post less accurate than it could have been), but, all things considered, the changes that would be necessary to keep fully-precise first-unread-message IDs are a bit too involved to justify, I think.
Based on the conversation about the "new" and "latest post" button we found in the "watchlist".
A little unrelated to your suggestion, but, since vapourminer's post about the placement of the "new" button, I've been half-seriously thinking that it might actually make sense to just
get rid of that button and then change the behavior of the "Last post" button to effectively cover both needs: I mean, how often do you need
specifically to get to the last post in a topic, rather than the first unread post? (For guests, it would still always take you to the last post, but when you're signed-in it would take you to the first unread post if there is one, or the last post, otherwise.)
I don't know if this suggestion has already been made, if it's doable or not, anyway, I submit it thinking "we never know.." : (...)
I like your suggestion and your thoughts very much! I'll think about them carefully. In the meantime, here are some thoughts that maybe you'll find interesting:
(*) There's already something (a little) related to this on my to-do list: Exporting PMs. With that one, at least some of the thinking is similar to yours, in that it would be easy for people to then once-in-a-while "delete" their PMs (after downloading a copy of them that they could manage locally, by importing them into Thunderbird, or something).
(*) I'm sure I've bumped into some form of the following idea a few times, but, I've been thinking for a while now about a way to embed easy-to-use client-side encryption/decryption into the PM system. The version of this idea that exists in my head would be almost entirely client-side (in JavaScript, or at least, something that
compiles to JavaScript) and would only involve a small server-side change to facilitate staking and looking-up public keys. I think more people would get into encrypting their PMs if the forum had a worked-out way to do that without expecting people to learn and then manually use PGP. (Another reason I think it would be wise for more people to encrypt their PMs is that Cloudflare can, in principle, see and save everything coming to/from your browser.)
(*) Something a little less related to this (but still relevant) is that I think a built-in
chat feature would be a really nice addition to Bitcointalk (the relevant idea being that anything that happens in chat wouldn't be long-term stored/persisted). I don't think I've shared this publicly, but, I had something really cool in mind for April Fools this year that I wasn't able to finish in time. I basically spent half of February and most of March programming my
balls off, and having/ignoring little anxiety attacks, before giving up right at the end (in hindsight, I had a lot of IRL stuff happening at the time, so it was stupid of me to bite off more than I could chew by taking on a time-sensitive project, but, yeah, the whole experience was pretty humbling: I haven't had to eat crow like that in something like 20 years). Anyway, necessity is the mother of invention, as they say, and while the walls were closing in on that project, I came up with a
really clever programming technique/abstraction that makes adding certain kinds of features to SMF much, much easier. With that in mind, I think adding a native, no-signup-required, encrypted/ephemeral chat feature where people could establish public (or private) "rooms" to have genuine (unincentivized, unlike a lot of posting) and short-feedback-loop conversations would be very feasible (and seriously cool).
For privacy, it doesn't help if the user has email notification for PMs.
That's a good point! Taking a quick look at the code, I think it would be pretty easy to improve this, maybe something like:
(I think either "Never" or "Always (subject only)" would make a better default for newly-registered accounts than "Always (with message)".)
Hmm interesting stuff, in terms of a full image-hosting solution, are you saying users would upload images to a 3rd party [p2p?] imagery DB that is delivering content based on a hash which is derived from the content of the image only?
That's right.
And it would then provide them a [cai] code?
Yes.
Or does the user somehow initiate the upload at the forum itself before it makes it to the storage/imagery DB-thingy?
That's how I'd
like it to work. But, for every 100 hours of energy I have for programming, I have like 6.5 seconds of energy for legal research, so I haven't looked into the ramifications: If it turns out that divorcing the forum itself from
storing the images isn't enough to legally absolve it, and that technically involving it with even just the
uploading process would still expose it to some amount of legal risk (I'm hoping that that's not the case, but, it certainly
sounds like the kind of tiresome bullshit that some asshat might have dreamed up), then, it wouldn't be able to work that way (in that case, it would have to work more like a traditional image-hosting solution in terms of how the images are uploaded, and some nice technical advantages would disappear, but the most important ones would remain).
It seems like this would effectively eliminate duplicates and re-used images that are identical but would
normally still occupy resources... seems pretty interesting.
Yup.
(You can even de-duplicate similar images, by defining the hashing to happen over something other than the raw bytes, like, say, over the image data after it's been moved into a consistent colorspace and simplified in various ways. But, I'm unlikely to pursue that. Fun to think about, though.)Would the storage nodes have actual file-based images or some sort of encrypted/compressed copy?
I'm not sure yet. Probably I'll explore a few different approaches. From experience, I know which approach I'll
try first (something amalgamated, to uncouple performance from the file system and have finer control over reads/writes).
And in terms of previously uploaded imgur images, if the intent would be to ultimately replace those links entirely with [cai]'s, it might still be best to keep some way to reference the original imgur link, in some fashion, to provide verification on top of whatever independent method is used.
Agreed.
