lena

joined 6 months ago
MODERATOR OF
[–] lena@gregtech.eu 5 points 18 hours ago

It's not even a loophole, this is how ActivityPub is designed

[–] lena@gregtech.eu 2 points 19 hours ago (1 children)

Why did it decide to reply to me lol

[–] lena@gregtech.eu 4 points 19 hours ago (4 children)

what is this supposed to be

[–] lena@gregtech.eu 48 points 19 hours ago (9 children)

They literally can't live without technology smh my head

[–] lena@gregtech.eu 40 points 19 hours ago* (last edited 19 hours ago) (8 children)

Hi, Lemvotes dev here. As you can imagine, I believe votes on the Fediverse should be public, because that's just how ActivityPub works. Votes are sent out to every subscribed instance, which can then do whatever it wants with them.

We need to stop pretending votes on Lemmy are private, they're not. By letting anyone view votes (well, they can do that without Lemvotes by setting up their own instance, Lemvotes just lowers the entry barrier), users can see, for example, who's serially downvoting their posts or a community's posts.

Also, I don't think votes being public ruins Lemmy. They're public on bluesky and (virtually) no one is complaining. Additionally, platforms like kbin and mbin, which are part of the Fediverse, already make votes public. So even without Lemvotes, people can view the votes on posts. Lemvotes just makes it a bit more convenient.

The only way to fully prevent anyone other than dbzer0 admins from viewing votes is to disable federation.

The way lemvotes works right now afaik, is it uses an admin level account to collect voting data from all federated instances, thus enabling the identification of every voter. This method effectively bypasses the guardrails the developers put in place to keep this info more restricted.

Just a technical nitpick, this is inaccurate. Lemvotes queries the Lemmy database directly, so instance admins can plug it into the db and Lemvotes is running. I was considering making Lemvotes its own Fediverse actor, so that (1) setting up an instance of Lemvotes would be easier, and (2) opting out would be simpler by simply defederating lemvotes.org (or wherever the instance is running), but after working on it for a bit (the results of my work are on this git branch), I realized I don't know enough about ActivityPub, and that I don't care enough about Lemvotes or Lemmy to spend my time on this, as I have other projects to work on. In case anyone wants to develop that themselves, they're free to do so! Lemvotes is open source.

[–] lena@gregtech.eu 6 points 1 day ago* (last edited 1 day ago)

kitty is hungry

[–] lena@gregtech.eu 20 points 1 day ago* (last edited 1 day ago) (3 children)

I have sinned. How can I repent?

Edit: there, I even downvoted myself

[–] lena@gregtech.eu -4 points 1 day ago* (last edited 1 day ago) (7 children)

Looks like windows 11 to me

edit: nevermind it's KDE, apologies, OP

[–] lena@gregtech.eu 2 points 1 day ago

Very eventful

And looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong

[–] lena@gregtech.eu 2 points 1 day ago (2 children)

Finally, I found the end of it

[–] lena@gregtech.eu 26 points 1 day ago (2 children)

Just a heads up, you linked to the same article twice

[–] lena@gregtech.eu 16 points 1 day ago (3 children)

Python 27??? Does tech in the future go full circle and starts to look like windows XP again?

 

Hi, what's the best way for testing a gin route?

I currently have one function where the routes are defined. Here it is:

package router

import (
	"github.com/gin-gonic/gin"
	"github.com/gragorther/epigo/handlers"
	"github.com/gragorther/epigo/middlewares"
)

func Setup(userUserStore handlers.UserUserStore, groupGroupStore handlers.GroupGroupStore, groupAuthStore handlers.GroupAuthStore, messageAuthStore handlers.MessageAuthStore, messageMessageStore handlers.MessageMessageStore, middlewareUserStore middlewares.UserStore) *gin.Engine {
	r := gin.Default()
	r.Use(middlewares.ErrorHandler())

	userHandler := handlers.NewUserHandler(userUserStore)
	authHandler := middlewares.NewAuthMiddleware(middlewareUserStore)
	groupHandler := handlers.NewGroupHandler(groupGroupStore, groupAuthStore)
	messageHandler := handlers.NewMessageHandler(messageMessageStore, messageAuthStore)

	// user stuff
	r.POST("/user/register", userHandler.RegisterUser)
	r.POST("/user/login", userHandler.LoginUser)
	r.GET("/user/profile", authHandler.CheckAuth, userHandler.GetUserProfile)
	r.PUT("/user/setEmailInterval", authHandler.CheckAuth, userHandler.SetEmailInterval)

	// groups
	r.DELETE("/user/groups/delete/:id", authHandler.CheckAuth, groupHandler.DeleteGroup)
	r.POST("/user/groups/add", authHandler.CheckAuth, groupHandler.AddGroup)
	r.GET("/user/groups", authHandler.CheckAuth, groupHandler.ListGroups) // list groups
	r.PATCH("/user/groups/edit/:id", authHandler.CheckAuth, groupHandler.EditGroup)

	// lastMessages
	r.POST("/user/lastMessages/add", authHandler.CheckAuth, messageHandler.AddLastMessage)
	r.GET("/user/lastMessages", authHandler.CheckAuth, messageHandler.ListLastMessages)
	r.PATCH("/user/lastMessages/edit/:id", authHandler.CheckAuth, messageHandler.EditLastMessage)
	r.DELETE("/user/lastMessages/delete/:id", authHandler.CheckAuth, messageHandler.DeleteLastMessage)
	return r
}

so, my question is, how can I test just one route? should I run this function in every test and send a request to a route with httptest? Or should I set up my handlers like it's described at https://gin-gonic.com/en/docs/testing/

(like this)

func postUser(router *gin.Engine) *gin.Engine {
  router.POST("/user/add", func(c *gin.Context) {
    var user User
    c.BindJSON(&user)
    c.JSON(200, user)
  })
  return router
}

let me know if you have any other questions about my code.

It's available on github: https://github.com/gragorther/epigo

 
373
Gary (infosec.pub)
 

Here are some more pics of these two birds:

 

(Shamelessly stolen from reddit)

45
Flowery [OC] (infosec.pub)
view more: ‹ prev next ›