tripflag

in that case I would feel comfortable going with a refurb like theloweststone mentioned; pixels are the only(?) android devices which let you swap out the bootloader in a safe manner, so even a phone that's been in shady hands should be fine if the boot hash matches. And if you know another person with graphene you can do the attestation just to be certain.

but since the future of GrapheneOS is slightly shaky at the moment, I've looking at alternatives for when my current device inevitably bites the dust -- fairphone and pinephone both look like decent choices at first glance. It's an unfortunate situation but just gotta roll with it!

what's stopping you? was the very first thing I did, don't regret it for a second -- https://ocv.me/b/img/IMG_20230811_121845_049.1ssy.jpg "i'm about to finish setting up my pixel alright" :p

So for example if you updated the file and need to re-upload it, there is no way for you to delete the previous one.

if this is something you'd fancy then copyparty might be worth a look -- it lets uploaders undo their own uploads within a configurable timeframe, even in folders where they only have write-only access (the ability to upload files without seeing existing files).

disclaimer: I'm the author -- and also thrilled to see someone else suggesting it in the thread!

So I realize the following does not directly apply in this specific case, since we are talking about a full android app. But in general, there are strictly technical limitations which absolutely requires you to use https. This for example applies to PWA's, and it also applies to apps which are WebView-based.

Basically the w3c is disagreeing with you; there are several important javascript features which are forcefully disabled if you are not connecting over https. This is a decision made by the webbrowser itself, and not something you or the dev can disable or otherwise avoid.

For example, it is impossible to use the browser's built-in api for getting the sha512 hash of a file, which is why i had to go through great pains to do that in other suboptimal ways in one selfhosted service i made. Most devs rightfully wouldn't bother, since those restrictions are arbitrary and effectively pointless, as there are (usually painful) workarounds.

List of features which require https: https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts

It depends who you ask (which we can already tell hehe), but I'd say YES, because you're the one running the show -- you're free to grab all of your bits and pieces at any time, and move to a different provider. That flexibility of not being locked into one specific cloud service (which can suddenly take a bad turn) is what's precious to me.

And on a related note, I also make sure that this applies to my software-stack too -- I'm not running anything that would be annoying to swap out if it turns bad.

Hadn't heard about PirateBox before -- love the concept, but nah aside from a small amount of overlap they're very different things :-)

When users join the PirateBox wireless network and open a web browser, they are automatically redirected to the PirateBox welcome page. Users can anonymously chat, post images or comments on the bulletin board, watch or listen to streaming media, or upload and download files inside their web browser.

I guess if you put copyparty on a raspberry pi (or boot the copyparty live-cd on a nuc) then you get something vaguely similar -- a wifi node where you can download and upload files, but none of the other stuff (chat, messageboard, captive portal). Maybe cool ideas for future spinoff projects hehe

Mind if I suggest my own software, copyparty?

Regarding authentication, someone who has an account (in this case just yourself) can create password-protected shares which other people can browse, or upload, or browse+upload to (configurable when creating the share).

There is WebDAV support, and it should integrate well enough with shares, but I haven't tested that specifically.

It has photo and video thumbnails, and a basic image-viewer, and with some elbow-grease it can also show exif-tags (gps-coordinates etc).

There is also optional file dedup, so if two people upload the same file, it'll detect and skip that during the 2nd upload (doesn't waste any bandwidth) and swap out the new file with a symlink to the existing one. Default disabled to avoid surprising someone with symlinks.

I think the following command would be enough to get you started:

wget https://github.com/9001/copyparty/releases/latest/download/copyparty-sfx.py
python3 copyparty-sfx.py -a sintan:yourpassword -v .::A,sintan --shr=/shr -e2dsa -e2ts

but since that's entirely unreadable, you can do it with a config file instead,

[global]
  e2dsa  # enable filesystem indexing 
  e2ts  # enable media indexing (music tags)
  shr: /shr  # enable shares under this url

[accounts]
  sintan: yourpassword 

[/]  # create a volume at this url
  /srv/share/partypics  # the filesystem path to share
  accs:
    sintan: A  # give sintan read-write-move-delete-admin

and use it like this:

python3 copyparty-sfx.py -c the.conf

there's another example here and here for inspiration.

off topic, but out of curiosity - why ogg (presumably vorbis) in favor of opus? maybe old devices or players, or just haven't made the change yet?

opus is also a xiph project, and is almost entirely transparent at "128kbps" (it's a misnomer for the q4 of vorbis), so it uses way less space for the same quality. I warmly recommend giving it a try if you haven't already.

one of the main reasons SQLite is gaining in popularity is because people are realizing it has higher performance than separate databases in many usecases. Keeping the communication in-process cuts a lot of overhead (network, memcpys). The fact that you also don't have to go through the trouble of configuring a separate service is just a bonus :-)

combine it with a service for uploading files to your server, there's dozens of those

Alpine also has the advantage of musl, which is a safer alternative to glibc, at the cost of some performance. So, if anything, I'd expect people to consider alternatives to Alpine for that reason, as alpine is already the best choice for security.

good idea, but a slight correction - mDNS and SSDP are entirely different things, rather SSDP was Microsoft's initial proprietary take on the idea, and mDNS was created as the new and improved standard.

mDNS does multicast (send/receive) on 224.0.0.251 and ff02::fb on port 5353, while SSDP uses 239.255.255.250 on port 1900 as you mentioned.

But I think OP's issue is that they're on different subnets; mDNS expects the server and the client to have a perfectly overlapping subnets inside the same LAN. If the server has 10.0.0.3/16 and 192.168.1.3/24 then the client must also have 10.0.0.7/16 and 192.168.1.7/24. Or, if you can tell the server software exactly which IPs to announce, then that might work too.

there are workarounds to this, using avahi reflector, but that thing is buggy -- specifically you need to disable NSEC on the server, and lock it to either IPv4 or IPv6.

I made some note on additional pitfalls while i was writing my own mDNS and SSDP servers for fun, they're at the bottom of this page: https://ocv.me/copyparty/helptext.html