I think a way to do this and still allow private or restricted feeds is to take advantage of the fact that URLs are encrypted under HTTPS. Have the RSS served via FastCGI or a dedicated handler that verifies read permissions for a URL token against a permissions database.[1]
I think you'd want the permissions database to affiliate auth tokens with email addresses or mobile numbers.
When you request to follow someone, you input your email address or mobile number. If they approve your request, you'll receive a link to generate a feed URL with your auth token included. You can then easily input that into your feed reader of choice.[2]
If you lose the feed URL/auth token, you can request a new one using the same email or mobile number. When and only when the resulting link is activated will the old auth token mapping be replaced.
--
[1] This design is inspired by Slashdot's old auth system, which allowed you to log in via a saved URL. While that was probably horribly insecure over HTTP, you could restrict it to an IP/subnet. In any case, now that HTTPS is widespread the security concerns are substantially mitigated.
[2] An issue I haven't figured out is how to prevent feedly, inoreeder, etc. from caching private feeds.
I also thought about RSS as a basis for social media (I call it 'Really Social Sites'), but I think trying to make certain stuff private is against the whole idea of pub/sub and therefor RSS. I'm not saying you're wrong though, I just think mixing private and public (that's where the word 'publish' is coming from, right?) makes it more confusing.
I do think there's a gap to fill in RSS based social media, because users of current social media would like to send a private message (or at least not public) from time to time. I basically cover this with a contact form and email, at the moment. Sounds crude and not very techy, but it works like a charm.
I think a way to do this and still allow private or restricted feeds is to take advantage of the fact that URLs are encrypted under HTTPS. Have the RSS served via FastCGI or a dedicated handler that verifies read permissions for a URL token against a permissions database.[1]
I think you'd want the permissions database to affiliate auth tokens with email addresses or mobile numbers.
When you request to follow someone, you input your email address or mobile number. If they approve your request, you'll receive a link to generate a feed URL with your auth token included. You can then easily input that into your feed reader of choice.[2]
If you lose the feed URL/auth token, you can request a new one using the same email or mobile number. When and only when the resulting link is activated will the old auth token mapping be replaced.
--
[1] This design is inspired by Slashdot's old auth system, which allowed you to log in via a saved URL. While that was probably horribly insecure over HTTP, you could restrict it to an IP/subnet. In any case, now that HTTPS is widespread the security concerns are substantially mitigated.
[2] An issue I haven't figured out is how to prevent feedly, inoreeder, etc. from caching private feeds.