In T11173#190811, @alexanderschmidt wrote:

I also think that the second option sounds better. I think we do it that way.
However, we have to agree exactly what should be publicly available. Following your suggestion and considering our website we would make the following attributes public:

• username
• avatar
• website
  
  We discuss the topic in our team and clarify when and how quickly we can implement it.

Just thought i'd throw in a couple of comments for the discussion as well, since of course i'm not there in person :)

The reason for at least having at least the first name would be to allow us to not show usernames in the UI unless we have to (which is always nice, because the username tends to be more... technical than the name they chose to put into the chosen name field, and because the username can't be changed, while the other name fields can, which is very much an important thing this day and age)

Having the profilepage field filled would be quite important for engagement purposes (so people can be pointed to the store page showing that user's details) - the website is not quite as important, but of course still useful (but having the profilepage as a fallback is important, because not everybody will have the website field filled in)

Thanks for the quick response, too! In the meantime, i have implemented functionality in the WIP patch on D21721 that just sort of expects some of this information to be available, which will make it easy to adapt it when you've got it implemented at your end, but which also has sensible fallbacks so that when the information is not (such as is the case at the moment) it will still look acceptable :)

How's this coming along? :) (i can't finish up the work i'm doing in D21721 without this and T11142 being done)

Just a quick poke, because i kind of need this to happen... how's it coming along? Thanks in advance! :)

OK, some person data are now public:

• username
• firstname
• avatar
• homepage
• profilepage

Example:

<ocs>
  <meta>
    <status>ok</status>
    <statuscode>100</statuscode>
    <message/>
  </meta>
  <data>
    <person details="summary">
      <personid>leinir</personid>
      <privacy>0</privacy>
      <privacytext>public</privacytext>
      <firstname>Dan Leinir</firstname>
      <lastname/>
      <gender/>
      <communityrole/>
      <homepage>leinir.dk</homepage>
      <company/>
      <avatarpic>
        https://www.pling.com/member/avatar/a09fca73524dca1a850c3004ebee86fe/800
      </avatarpic>
      <avatarpicfound>1</avatarpicfound>
      <bigavatarpic>
        https://www.pling.com/member/avatar/a09fca73524dca1a850c3004ebee86fe/800
      </bigavatarpic>
      <bigavatarpicfound>1</bigavatarpicfound>
      <birthday/>
      <jobstatus/>
      <city/>
      <country/>
      <latitude/>
      <longitude/>
      <ircnick/>
      <ircchannels/>
      <irclink/>
      <likes/>
      <dontlikes/>
      <interests/>
      <languages/>
      <programminglanguages/>
      <favouritequote/>
      <favouritemusic/>
      <favouritetvshows/>
      <favouritemovies/>
      <favouritebooks/>
      <favouritegames/>
      <description/>
      <profilepage>https://www.pling.com/u/leinir</profilepage>
    </person>
  </data>
</ocs>

This also is looking great! If we could make avatarpicfound be 1 and 0 (rather than true and false), that would be super handy, as that would allow me to not have to change attica's parser, which expects something which can be converted into an integer.

(it's also what the spec suggests, though reasonably we would probably want to ensure that both the string and numeric style boolean values are supported for future use)

Done

Thank you very much :) i shall follow up with a screenshot when i've got it all happy :)

And there we go, ain't it a lovely thing ;)

Looks wonderful indeed! :)