Now that we've got the new badge, the YAML rule can be written

Hi @jonatoni. I was approved the initial application for Outreachy May-August 2019 and would like to try making a contribution. Let me know please if this issue is available. Thanks :)

Hi @jonatoni. I am an outreachy applicant. I would like to be assigned this ticket Thanks.

This issue is blocked by #96. fedora-happiness-packets needs to migrate to the fedora-messaging API from fedmsg, from the context in fedora-infra/fedmsg#426. This work was already started by @denim in fedora-badges#653, but that pull request is blocked by the fedora-messaging migration.

This is not a great ticket to start with. I recommend looking at #96 first.

@jflory7 With fedmsg, Messages on the Bus were send ie a badge was rewarded when a sender and receiver confirmed to post the message in archives. The workflow should be to award a badge when a receiver has confirmed sending the message. I might be interpreting the desired functionality wrong. Could you please give your thoughts on this?

@shraddhaag This is a great question, I'm realizing there is some trickiness to this since some Happiness Packets may be sent anonymously.

My first thought is we should emit one message per packet. The contents of the message depend if the sender wishes to share their identity or be anonymous. If willing to share identity, a fedora-messaging event might be something like jflory7 sent a Happiness Packet to jonatoni. If anonymous, it would be something like Someone sent a Happiness Packet to jonatoni.

This way, we should be able to get both the sender and receiver of a Happiness Packet in the same message (i.e. we can script different badges for sending or receiving a packet). One downside to this is it is impossible for a receiver to remain anonymous on the bus, but I think this is okay since the message itself is not shared.

What do you think?

My first thought is we should emit one message per packet.

I agree. That will refrain from noise in the bus from our project.

One downside to this is it is impossible for a receiver to remain anonymous on the bus.

Umm, I don't understand this. Why does the sender needs to be Anonymous?

As i understand, when a sender sends a happiness packet they choose to remain anonymous from the receiver. Whether they send it anonymously to the receiver or not, they would want to be awarded with a badge for the package they sent and same goes for receiver, Since our project requires a user to be logged in to send a happiness packet, we would always know the sender. As you said, we don't share the message, no security breach is observed. Thus I think only one case needs to be considered where X send a Happiness Packet to Y where both X and Y are known variables.

Or is it something I'm missing? Please let me know

Umm, I don't understand this. Why does the sender needs to be Anonymous?

As i understand, when a sender sends a happiness packet they choose to remain anonymous from the receiver. Whether they send it anonymously to the receiver or not, they would want to be awarded with a badge for the package they sent and same goes for receiver, Since our project requires a user to be logged in to send a happiness packet, we would always know the sender. As you said, we don't share the message, no security breach is observed. Thus I think only one case needs to be considered where X send a Happiness Packet to Y where both X and Y are known variables.

I chatted with @jonatoni about this today to clarify.

A sender may remain anonymous when they send a Happiness Packet. The sender of an anonymous Happiness Packet doesn't want their username to appear on the fedora-messaging bus. It would be possible for someone to figure out the identity of a sender of their Happiness Packet by querying fedora-messaging with datagrepper. In this case, an anonymous Happiness Packet fedora-messaging event should also anonymize the sender.

We also thought that if someone is sending an anonymous Happiness Packet, they probably have more motivation to do it than to earn a badge. I think it's acceptable if someone sends an anonymous badge, they won't receive a badge.

It would be possible for someone to figure out the identity of a sender of their Happiness Packet by querying fedora-messaging with datagrepper.

Aah! I didn't know of this. :sweat_smile: I understand the security concerns this might create. Users must have a control over their privacy. I got the point I was missing.

We also thought that if someone is sending an anonymous Happiness Packet, they probably have more motivation to do it than to earn a badge. I think it's acceptable if someone sends an anonymous badge, they won't receive a badge.

Oh yes! Honest intentions while sending an appreciation message should be respected above all. :smile:

A couple of quick question just to make sure we are on the same page:

1. The sender may be anonymous or known. As a first thought, this could be implemented as, if the sender chose to share the name with receiver, then we put the name in the message on the bus too. If he didn't choose to share the name with the receiver in the mail, we can keep their identity anonymous on the bus too.
   Will this be okay or should we have a dedicated field asking if they want to be anonymous on the bus ie receive a badge or not?

2. The message is any case shouldn't be propagated to the bus. Thus a static body as Happiness Packet, as you mentioned above, will suffice?

3. The receiver's identity is always known on the bus.

@jflory7 Did I get capture it right this time?

Aah! I didn't know of this. 😅 I understand the security concerns this might create. Users must have a control over their privacy. I got the point I was missing.

Super, glad we cleared it up! :thumbsup:

1. The sender may be anonymous or known. As a first thought, this could be implemented as, if the sender chose to share the name with receiver, then we put the name in the message on the bus too. If he didn't choose to share the name with the receiver in the mail, we can keep their identity anonymous on the bus too.

Will this be okay or should we have a dedicated field asking if they want to be anonymous on the bus ie receive a badge or not?

I agree, if the sender shares their name with the receiver, I think it follows that their FAS username will appear on the bus. :arrow_right::bus:

1. The message is any case shouldn't be propagated to the bus. Thus a static body as Happiness Packet, as you mentioned above, will suffice?
   

I'm not sure I understand. Do you mean the Happiness Packet message itself? The HP message should not be relayed to the bus and should always remain private.

1. The receiver's identity is always known on the bus.
   

Correct!

I'm not sure I understand. Do you mean the Happiness Packet message itself? The HP message should not be relayed to the bus and should always remain private.

I meant the packet body that is actually delivered to the recipient on the mail shouldn't be propagated on the bus. A static body sent a Happiness Packet would work okay right? I've implemented it the same way in the PR #161

I meant the packet body that is actually delivered to the recipient on the mail shouldn't be propagated on the bus. A static body sent a Happiness Packet would work okay right? I've implemented it the same way in the PR #161

Correct! :thumbsup:

To follow up on me and @shraddhaag's discussion today, one task we could work on in advance is writing the Badge definition file for Fedora Happiness Packets. There is a little documentation on the Open Badges wiki page, but it could be better. There is also some helpful context on the Badges website itself, but some of this is definitely dated.

Here are some resources for getting started with Fedora Badges rules:

• Fedora Badges Badge Builder: Simple tool to build skeleton YAML for a new badge in the correct format
• All existing rules: The best way to learn how to write Badges rules are by looking at the existing ones, which exist here.
  • cookie-01, cookie-02, cookie-03, cookie-04, cookie-05, cookie-06, cookie-07: Specific examples of some badges that function similarly to FHP message senders/receivers

This should be enough to get started. The other pre-requisite for this is knowing how FHP's packets are structured to write the correct fedora-messaging query to extract the correct data. We won't be able to test this before we deploy to staging or production, but we can put together a few rules based off of what we know now.