List of existing pastes

[potokslow]

Hi,

Is there a way to have all existing pastes listed on the home page, or have a separate page with such list? This would be very helpful for managing the pastes.

Thank you

[matze]

I guess a REST call is not enough?

[potokslow]

I think that having pastes listed on a web page would be easier to use than API.

REST call could work in the absence of a web list, but please include an example of such call in the readme. I have no idea how to request the list...

[matze]

Okay, I have some PoC but I am not sure how this is really that useful. At the end of the day it's just a list of links. Is it really all you need?

[potokslow]

The main points behind this idea are to:

• find and remove old entries,
• find entries for which links were lost. A chronological list of pastes would be sufficient for this.

Ideally, it would be great to have a table with:

• paste creation date,
• expiration date, if set,
• something to act as a title for each paste - e.g. first line up to 32 characters,
• encryption info (true / false).

Thank you

[matze]

Unfortunately, creation date is not stored (anymore). Title would be possible but depending on the size of the database, I am not sure we are coming into denial-of-service area. In fact, I am already a bit worried dumping the entire list each time. On the other hand, I am also a bit too lazy to implement pagination now. So this is what I could offer:

[PinguDEV-original]

Or maybe just use sqlite SELECT * FROM entries;? You can also remove stuff this way (DELETE FROM entries WHERE id = ID)

[kamaradski]

I actually think it's a feature that none of the visitors is able to see what other people posted, unless you have the exact link. If anything i would argue to make the random link longer and thus harder to guess.

Unless obviously you also want to go through the rabbit hole of creating a public-flag not unlike pastebin

EDIT:

Actually thinking about this more i might have a good idea.

Since the usecase is "managing the pastes", i can assume it will be the sysadmin who will use this feature. Since I personally do not think this project need a user management (for all the fancy stuff there are already alternative platforms you can use), but instead remain to be slick, slim, and fast. So creating an admin feature is probably out of scope.

This basically leaves cli-tools to solve this problem

• usermanagement: whatever the host OS is offering should be enough for this usecase
• multi platform: this should work for docker (docker exec -it ) as well as for native installations
• with the right amount of documentation (and/or cli UX design) this should be userfriendly for everyone that has the skillset to host this platform in the first place

Pro:

• compatible with most scenarios and setups i can think of from the top of my head
• can be expanded with other functionality very quickly and effortlessly
• these are cli-tools, they are fast by design
• as these scrip(s) are small and only running on demand, they do not make the overall system any slower or enlarge the codebase by much
• with little extra effort these can even have a rudimentary ux
• these are secure, since only available on the OS level
• such scripts also allow automation for example running as cronjob on the host OS

Con:

• it's basically a split UI/UX from the main website (though in DevOps/IT it's normal to maintain a system from it's cli)
• ? cant see much more

I personally like this idea for it's (probably) low efforts to implement, and this can probably recycle a lot of existing functions/code.

[joser93]

+1 this idea, besides, can be related with #54 to keep trace of the usage for the server and force the expiration specific files.

[jichef]

It would be a great idea. In my case I make a paste from a server and on other I wouldn't need to write the complete link to access what I pasted. It would be much easier.

[matze]

I personally like this idea for it's (probably) low efforts to implement, and this can probably recycle a lot of existing functions/code.

Thanks for the suggestion (and sorry for the late reply). I like the idea as well but I think we should flesh out a reasonable design in a separate issue.

[matze]

I mean outlining what the tool(s) should be capable of doing, what the UI should look like etc. should not be discussed here but in a separate GitHub issue.

jichef @.***> schrieb am Fr., 8. Nov. 2024, 23:54:

I personally like this idea for it's (probably) low efforts to implement, and this can probably recycle a lot of existing functions/code.

Thanks for the suggestion (and sorry for the late reply). I like the idea as well but I think we should flesh out a reasonable design in a separate issue.

Thank you! anyway... don't understand what you mean... sorry.

— Reply to this email directly, view it on GitHub https://github.com/matze/wastebin/issues/59#issuecomment-2465871242, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA4ERRBWG2OBGCEWNWZGRLZ7U6LDAVCNFSM6AAAAABJXEWBTOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRVHA3TCMRUGI . You are receiving this because you commented.Message ID: @.***>