I _think_ for multi-user pods, _some_ level of trust has to exist between its users (a pod's small community) and its operator -- I mean after-all I run twtxt.net as a multi-user pod free of charge and free from ads, etc, etc š
I _think_ for multi-user pods, _some_ level of trust has to exist between its users (a pod's small community) and its operator -- I mean after-all I run twtxt.net as a multi-user pod free of charge and free from ads, etc, etc š
A user of a pod certainly needs to trust the operator to some extent. Abuse of admin powers by the operator of your own pod isn't a big concern in theory because it can be countered by moving to a different pod or self-hosting your feed.
However, admin abuse is a real concern when the admin of a pod you're not using gets to police the content of your posts.
> "Delete and Redirect"
That's a great idea.
Sorry I'm pulling this topic into an already complex thread ;-), specially when I was supposed to write a proposal for this change, and never did (yet?)...
Sorry I'm pulling this topic into an already complex thread ;-), specially when I was supposed to write a proposal for this change, and never did (yet?)...
I _think_ there was a good reason to only allow the
# prev field to be relative, so that feed authors (malicious ones) couldn't just arbitrarily point a feed to some other random feed that wasn't there or something. I _think_ @movq wrote the spec if I'm not mistaken. I agreed with it at the time, I think I still do and yarnd fully implements it as of a few weeks ago.Why do you think redirects won't work for deleted feeds/accounts? I've seen that before I _think_ on Bitbucket of all places, where if you delete a repo, you can tell the system where the new location will be.
I _think_ there was a good reason to only allow the
# prev field to be relative, so that feed authors (malicious ones) couldn't just arbitrarily point a feed to some other random feed that wasn't there or something. I _think_ @movq wrote the spec if I'm not mistaken. I agreed with it at the time, I think I still do and yarnd fully implements it as of a few weeks ago.Why do you think redirects won't work for deleted feeds/accounts? I've seen that before I _think_ on Bitbucket of all places, where if you delete a repo, you can tell the system where the new location will be.
Regarding
# prev, maybe it is best to recover the old thread (which I think was (#opev6mq)).
Regarding
# prev, maybe it is best to recover the old thread (which I think was (#opev6mq)).
https://search.twtxt.net/search?q=conv%3a%23opev6mq&p=1&t=qs&s=created&s=_id
https://search.twtxt.net/search?q=conv%3a%23opev6mq&p=1&t=qs&s=created&s=_id
# prev relative were multi-protocol feeds, pretty sure. (I havenāt read the rest of this massive thread.)
# prev relative were multi-protocol feeds, pretty sure. (I havenāt read the rest of this massive thread.)
# prev relative were multi-protocol feeds, pretty sure. (I havenāt read the rest of this massive thread.)
# prev relative were multi-protocol feeds, pretty sure. (I havenāt read the rest of this massive thread.)
yarnd (Yarn.social pods) and yarns (Twtxt Search Engine) implements this is as per-the-spec, where it is treated as # prev = <hash> <relative-path> -- So if we want to support absolute URIs, we're going to have to make an amendment to the spec and to implementations that already implement it.
yarnd (Yarn.social pods) and yarns (Twtxt Search Engine) implements this is as per-the-spec, where it is treated as # prev = <hash> <relative-path> -- So if we want to support absolute URIs, we're going to have to make an amendment to the spec and to implementations that already implement it.
https://git.mills.io/yarnsocial/yarn/pulls/494
It was indeed more than just āmulti-protocolā: Having a relative URI also makes it easier to move your entire feed (including archived feeds) to another domain.
We quickly settled on relative URIs, there wasnāt that much of a discussion in the PR. Probably just felt like the right thing to do. š¤
https://git.mills.io/yarnsocial/yarn/pulls/494
It was indeed more than just āmulti-protocolā: Having a relative URI also makes it easier to move your entire feed (including archived feeds) to another domain.
We quickly settled on relative URIs, there wasnāt that much of a discussion in the PR. Probably just felt like the right thing to do. š¤
https://git.mills.io/yarnsocial/yarn/pulls/494
It was indeed more than just āmulti-protocolā: Having a relative URI also makes it easier to move your entire feed (including archived feeds) to another domain.
We quickly settled on relative URIs, there wasnāt that much of a discussion in the PR. Probably just felt like the right thing to do. š¤
https://git.mills.io/yarnsocial/yarn/pulls/494
It was indeed more than just āmulti-protocolā: Having a relative URI also makes it easier to move your entire feed (including archived feeds) to another domain.
We quickly settled on relative URIs, there wasnāt that much of a discussion in the PR. Probably just felt like the right thing to do. š¤
Thanks!, reading that was useful.
It seems to me that the choice of 'relative' was meant to consider users' use cases (multi-protocol, moving the feeds from one place to another, etc.), without any added convenience to the clients, specifically. Thus, I'd argue that there is nothing against extending the spec to also allow full paths: current users are unnafected, and we'd be catering for new/other use cases.
Yes, I do realize that would mean this would have to go into a new
Thanks!, reading that was useful.
It seems to me that the choice of 'relative' was meant to consider users' use cases (multi-protocol, moving the feeds from one place to another, etc.), without any added convenience to the clients, specifically. Thus, I'd argue that there is nothing against extending the spec to also allow full paths: current users are unnafected, and we'd be catering for new/other use cases.
Yes, I do realize that would mean this would have to go into a new version of the spec, and clients would have to implement it in order to comply with the new version of the spec.
Thanks!, reading that was useful.
It seems to me that the choice of 'relative' was meant to consider users' use cases (multi-protocol, moving the feeds from one place to another, etc.), without any added convenience to the clients, specifically. Thus, I'd argue that there is nothing against extending the spec to also allow full paths: current users are unnafected, and we'd be catering for new/other use cases.
Yes, I do realize t
Thanks!, reading that was useful.
It seems to me that the choice of 'relative' was meant to consider users' use cases (multi-protocol, moving the feeds from one place to another, etc.), without any added convenience to the clients, specifically. Thus, I'd argue that there is nothing against extending the spec to also allow full paths: current users are unnafected, and we'd be catering for new/other use cases.
Yes, I do realize that would mean this would have to go into a new version of the spec, and clients would have to implement it in order to comply with the new version of the spec.