jak2kI don't understand the purpose of delete/undelete in Micropub. Undelete implies that delete only marks entries as deleted. This means it only hides the post, which is functionality also provided by status and visibility (which have overlapping functionality too).
Loqiunlisted are publicly visible posts that are not included in a homepage or feed(s), and are typically excluded from site search features and broader web search services https://indieweb.org/unlisted
[manton]It’s mostly up to the implementation. For example, in http://Micro.blog, a Micropub delete really deletes the post, and we don’t support undelete.
gRegorA deleted post wouldn't (shouldn't) be viewable anywhere publicly. An unlisted post is still publicly viewable, if you have the URL. Subtle but important difference
[tantek]most systems, smart phones, laptops, when you "delete" an image or a file, it goes into a "Trash", where you can then go get it and "recover" (undelete) it.
[tantek]pretty sure nearly EVERY "delete" action on iOS (photos, notes, etc.) moves things to a "Trash" or "recently deleted" area, from which you can recover them.
Loqi[preview] [[tantek]] it doesn't "actually" get deleted typically either for 30 days, or until the user explicitly says "empty trash" or something similar
[snarfed]label seems to imply user-defined, while status usually seems different, system-defined, with a limited set of values that do have specific semantics, eg draft, scheduled, published, deleted
[snarfed]sure. seems like status deleted would similarly fit and only change based on user action, right? and all of those statuses have semantics side effects too, not just deleted, right?
[snarfed]ah, sorry, I see what you mean now. I only mean that the possible status *values* were system-defined, not user-defined. it definitely does *change* on user action, like labels!
[snarfed]I mean, I get scheduled => published, which is a status change that happens automatically, without direct user interaction, and seems fine and expected
[snarfed]otherwise I'm with jak2k, I don't see other cases yet, other than eg status deleted => fully purged after 30d or so, which changes the whole post, not just its status
[tantek]scheduled as it is a modifier on "publish" (create), and similarly, for ephemeral posts, that's a scheduled delete. there are also posts that need to be updated at a certain time (e.g. event details like a Zoom link 10min before the event), and that would be a scheduled update.
[tantek]jak2k, there are extremes, e.g. you can design a protocol with one verb, "do something", and then put everything else into properties. or you can have tons of verbs for every possible action/activity and then have only one property "content" that depends on the verb for what it does. both are bad design. the point is to reflect different actions (especially with side-effects) as part of a protocol, and ideally the properties are all user
btremRegarding the mess I'm with trying to get an iCal feed working, part of the blame goes to the whole webdav thing. Someone (Tantek, I think), said that we need an update to webdav, to something based on h-event. A swell idea, but Google won't adopt h-event unless they have to, and as long as they have enough market share for their calendar sans h-event support, I don't see that happening.
[tantek]btrem, indeed, large provider adoption is often (usually?) a trailing indicator. Better to work on smaller provider adoption, then when there's a sufficient ecosystem, the larger providers are easier to convince.
LoqiIt looks like we don't have a page for "chat archives" yet. Would you like to create it? (Or just say "chat archives is ____", a sentence describing the term)
btrem[tantek]: I agree. But it means there's probably no point in updating webdav/webcal to h-event. Because the apps that people use won't consume it.
[tantek]From an indieweb perspective it doesn't matter if "the apps that [random] people use won't consume it" it matters only if the apps you're building and using (create what you need) will
LoqiIt looks like we don't have a page for "create what you need" yet. Would you like to create it? (Or just say "create what you need is ____", a sentence describing the term)
LoqiMake what you need is an IndieWeb principle that helps creators focus on creating & publishing things prioritized by what they need & want for their own personal site https://indieweb.org/make_what_you_need
Loqiuse what you make is an IndieWeb principle that encourages creators to use the applications, tools, libraries, code, designs, documentation that they create, in particular on their personal website, and the counterpart of the make what you need principle https://indieweb.org/Use_what_you_make
gRegorUnfortunately, creating a shared calendar in Google Calendar that you then grant the community access to read/write might be the most userfriendly option you have currently :/
btremIt's not just an abstract principle for me. Going the practical route means posting events on our website, and them copying them to a community calendar, e.g., Google calendar. And having people subscribe to /that/. Not DRY. Practically guaranteed to get out of sync. Probably sooner than later.
btremAnd since the Google calendar is the one people would depend on, the likely outcome is that the events data that we own will be the data that's neglected.
[tantek]it's not ideal sending everyone in the community to use gCal as their UI, however it's at least *a* solution, and you keep a copy of all the events in data you do own
btremAnd even if it did, what would that solve? I'm not being petulant. I can already (probably) create an .ics feed. The problem is making it available to google cal.
LoqiIt looks like we don't have a page for "authenticated ICS" yet. Would you like to create it? (Or just say "authenticated ICS is ____", a sentence describing the term)
Loqi[preview] [gRegor Morrill] @btrem.com: Here is what I found with an ICS file behind authentication.
I set up Basic authentication for this URL:
https://staging.gregorlove.com/indieweb/ics/calendar.ics
The username and password for this are both “guest”.
In the browser, ...
btremI'll quote from that discussion: "The thing is the coop has about 40-50 members. needs to be password protected, needs to have multiple contributors with different access, etc. none of which I want to code myself. So it sort of had to be a framework of some kind."
btrem"The thing is the coop has about 40-50 members. needs to be password protected, needs to have multiple contributors with different access, etc. none of which I want to code myself. So it sort of had to be a framework of some kind."
btremOops, sorry. Let me try that again: "Sure, I could do the secret-in-url thing, but the coop this .ics is for has almost entirely non-techie people who will absolutely *not* understand that their url is not to be shared."
gRegorAnecdotally, and only with a few people, but I've not usually had issues with people sharing the secret ICS urls from gcal outside where they should. It's mostly a one-time use thing, subscribe and hopefully it just works
aaronpkthe fundamental limitation here is that most calendar software doesn't support the idea of authenticated ics feeds, and instead uses secret URLs and big warnings about "don't share this"
LoqiIt looks like we don't have a page for "capability" yet. Would you like to create it? (Or just say "capability is ____", a sentence describing the term)
LoqiIt looks like we don't have a page for "fantastical" yet. Would you like to create it? (Or just say "fantastical is ____", a sentence describing the term)
btremWhich makes me think I should just wade into Drupal and try to create an .ics feed. Available to everyone, but if you use google cal your SOL. :-p
gRegorHeh, it's an even worse UX than I thought. Tried adding it by URL again and it just says "fetching events in the background" and creates an empty calendar. No indication there was an error.
btremThe UX for Thunderbird calendar and Ubuntu calendar is not great, either. If it subscribes, it's all good. But neither app handles "you need to be authorized" very well. I already complained about this when I started on this journey, lo those many weeks ago.
btremTo sum up: if auth is handled at the application level (in my case, php/Drupal), then the http response code is 200 OK. So the apps don't know what to do.
btremaaronpk: to respond to your "...small business..." question. I dunno. It's a housing coop. We have meetings and other events. We have no easy way to plan or announce meetings, or have someone reply that they're attending. The only announcement mechanism is a post on the website, managed by Drupal.
btremIf the site, and an events feed generated from it, were public, I think this would be easy to solve. Might have been solved already, at least the minimum part.
btremYes. Sorry, this conversation is only part of the story. It started -- a few weeks ago -- with "why doesn't .ics feed work?" Then "what is webdav, how is it related to .ics?" And then, "google cal doesn't support .ics with auth." That's where we are today.
btremAnd I started off today saying there's no point in building something in Drupal for auth .ics if a significant number of users won't be able to use it because Google.
btremSo I'm weighing pros and cons, which I was doing in a private chat with gRegor. Then I thought about what [tantek] said when I first brought up webdav/webcal, that we need an update to .ics that's based on h-event. And I pointed out that such a thing won't really help as long as Google doesn't support it.
btrem[tantek]: I missed your comment. But I was heading out the door to run errands, but thought before going that I'd thank everyone for the discussion. It's bee, as you said, illuminating, and I hope it will be helpful to me. More to come, no doubt. Thanks to everyone for sharing your insights.
[artlung]Weirdly my girlfriend just spent a painful amount of time trying to sort out when the games for the local FC had home games, putting them on a shared calendar, to warn us about the pet-alarming fireworks that happen at the end of the games. (they are loud and concussive and last night they ruined a dog walk)
cophee This happened when I tried to login the indieweb wiki with Indiekit as my website's auth
[KevinMarks] One for Front End Study Hall https://bsky.app/profile/twnsnd.com/post/3ltm6vh5qx22c
Loqi unlisted are publicly visible posts that are not included in a homepage or feed(s), and are typically excluded from site search features and broader web search services https://indieweb.org/unlisted
[manton] It’s mostly up to the implementation. For example, in http://Micro.blog, a Micropub delete really deletes the post, and we don’t support undelete.
[aciccarello] It's a good UX pattern to make destructive actions (e.g. delete) reversible. At least temporarily.
gRegor Learned of this open source search that has an option under "Optics" to search "indieweb and blogroll" https://stract.com/
[tantek] jak2k, there are extremes, e.g. you can design a protocol with one verb, "do something", and then put everything else into properties. or you can have tons of verbs for every possible action/activity and then have only one property "content" that depends on the verb for what it does. both are bad design. the point is to reflect different actions (especially with side-effects) as part of a protocol, and ideally the properties are all user
[artlung] Weirdly my girlfriend just spent a painful amount of time trying to sort out when the games for the local FC had home games, putting them on a shared calendar, to warn us about the pet-alarming fireworks that happen at the end of the games. (they are loud and concussive and last night they ruined a dog walk)